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I.  INTRODUCTION 


This  thesis  addresses  issues  related  to  the  reuse  of  software  components  in  support 
of  a  computer  aided  rapid  prototyping  environment.  The  specific  system  addressed  in  this 
thesis  is  the  Software  Base  component  of  the  Software  Database  System,  a  subsystem  of 
the  Computer  Aided  Prototyping  System  (CAPS).  This  portion  of  the  Software  Database 
System  stores  previously  developed  Ada  components  for  potential  reuse  by  other 
programs  or  subprograms. 

This  chapter  provides  background  on  some  of  the  issues  related  to  reuse  of  software 
in  general  and  the  applicability  of  reuse  to  the  rapid  prototyping  environment  provided 
by  CAPS.  Succeeding  chapters  present  an  overview  of  reuse  concepts  including  some 
of  the  more  promising  methods  and  research  in  this  area.  This  is  followed  by  an 
evaluation  of  the  current  state  of  the  Software  Base  component  of  the  CAPS  system  and 
the  use  of  the  Prototyping  System  Description  Language  (PSDL)  as  the  basis  for 
classification  and  retrieval  of  software  components  from  the  reusable  software  base. 
Domain  analysis  and  its  applicability  to  software  development  will  be  discussed  via  an 
example,  the  Common  Ada  Missile  Parts  (CAMP)  project  sponsored  by  the  Air  Force  and 
performed  by  McDonnell  Douglas  Corporation  from  1984-1988  [Ref.  1].  A  conceptual 
design  of  a  software  base  incorporating  the  results  of  the  CAMP  domain  analysis,  object- 
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oriented  concepts,  and  use  of  an  augmented  form  of  PSDL  as  the  base  language  for 
classification  and  retrieval  of  components  is  presented  and  contrasted  with  the  CAMP 
methodology. 

This  thesis  addresses  the  specific  problem  of  integrating  reuse  of  Ada  components 
into  CAPS.  However,  the  methodology  for  development  of  the  object  hierarchy,  the  basic 
rules  for  search  path  derivation,  and  the  pattern  matching  process  used  in  the 
transformation  of  the  augmented  PSDL  specification  to  a  set  of  candidate  reuse  classes, 
could  easily  be  adapted  to  reusable  components  in  other  programming  languages  or  other 
reusable  entities.  Some  suggestions  of  other  reusable  entities  which  may  become 
candidates  for  inclusion  in  the  Software  Base  are  included  in  the  concluding  section  of 
this  thesis. 

A.  THE  SOFTWARE  CRISIS 

The  demand  for  larger  and  more  complex  software  systems  continues  to  increase. 
Software  development  is  a  complex  process.  Programming  large  software  systems 
involves  teams  of  developers,  working  on  various  parts  of  the  system.  Coordination  of 
this  effort  is  an  immense  task.  Our  inability  to  deal  with  this  complexity  often  results  in 
software  projects  that  are  late,  over  budget,  and  deficient  in  their  stated  requirements.  The 
problem  involves  not  only  the  high  cost  of  software  development,  but  also  in  the  poor 
quality  of  existing  software  [Ref.  2:  p.  3].  Modification  is  so  difficult  that  maintenance 
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soaks  up  more  than  half  of  the  total  resources.  This  state  of  affairs  is  sometimes  called 
the  "software  crisis"  [Ref.  3:  p.  243]. 

While  all  acknowledge  that  the  problem  is  there,  few  have  any  short  term  solutions. 
In  fact,  it  is  estimated  by  many  that  we  arc  still  10-15  years  away  from  having  the  tools 
we  need  to  build  the  systems  we  would  like  to  have  now  in  a  reliable  manner  [Ref.  4]. 
Research  on  the  solutions  to  fhe  software  crisis  seems  to  concentrate  on  three  main  areas: 
programming  ?nd  specification  languages,  prototyping  and  knowledge  based  development, 
and  reuse  of  software  artifacts.  Most  development  work  on  advanced  software 
environments  includes  elements  of  all  of  these  areas  but  few  are  concentrating  on  the 
integration  of  all  of  these  areas  into  a  comprehensive  environment  which  will  have  any 
short  term  (within  the  next  five  to  ten  years)  impact. 

B.  RELATED  AREAS  OF  RESEARCH 

The  next  sections  briefly  describe  some  of  the  major  areas  of  research  involved  in 
software  development.  All  have  potential  long  range  benefits,  but  many  are  in  the  early 
stages  of  development. 

1.  Programming  and  Specification  Languages 

This  area  addresses  the  support  of  sound  software  engineering  practices 
through  the  development  of  languages  that  support  the  development  of  reliable  systems. 
This  includes  both  High  Order  Languages  (HOL)  that  support  the  conventional 
development  and  Very  High  Level  Languages  (VHLL)  used  primarily  in  artificial 
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intelligence.  In  the  area  of  HOL  support  the  Department  of  Defense  took  the  lead  with 
the  decision  to  designate  Ada  as  the  language  for  DoD  systems.  The  development  of  Ada 
as  a  language  that  offers  great  expressive  power,  is  tightly  controlled  as  a  language,  and 
demands  the  use  of  sound  software  engineering  practices  is  already  showing  benefits  in 
the  development  of  software  within  DoD  [Ref.  2:  p.  8].  Very  High  Level  Languages 
have  great  expressive  power  and  most  allow  the  use  of  symbolic  expressions  to  represent 
functions  and  rules  that  support  the  development  of  expert  systems.  They  have  proven 
to  have  the  most  benefit  in  limited,  domain  specific  areas  where  knowledge  can  be 
represented  in  the  form  of  facts  and  rules.  They  have  been  used  to  a  limited  extent  in  the 
software  development  and  show  great  promise,  particularly  in  the  area  of  specification 
assistance.  The  most  notable  efforts  in  this  area  are  the  Programmers  Apprentice  project 
at  MIT  and  the  Specification  Assistant  portion  of  the  Knowledge  Based  Software 
Assistant  project  at  Rome  Air  Development  Center  [Ref.  4].  Other  notable  VHLL’s 
include  REFINE  developed  and  distributed  by  Reasoning  Systems  Inc.  and  GIST 
developed  by  the  ISI  at  the  University  of  Southern  California  [Ref.  4], 

2.  Prototyping  and  the  Use  of  Expert  Systems 

Most  of  the  major  efforts  in  this  area  are  focused  on  very  narrow  domains. 
Prototyping  is  used  in  two  primary  contexts:  as  a  tool  to  define  user  interfaces,  or  as  a 
method  to  test  all  or  part  of  a  system  prior  to  entering  a  full  scale  development  effort. 
A  great  deal  of  the  effort  involved  in  prototyping  is  on  the  validation  of  user  requirements 
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at  an  early  stage  of  system  development.  This  validation  has  the  potential  to  greatly 
reduce  both  the  cost  and  time  required  to  develop  systems.  In  the  context  of  software 
development  expert  systems  are  used  to  aid  the  process  through  the  use  of  knowledge 
about  the  process  as  well  as  knowledge  about  specific  problem  domains.  It  is  anticipated 
that  many  of  the  database  intensive  activities  being  performed  today  will  be  replaced  by 
expert  systems  and  knowledge  based  techniques  in  the  future. 

3.  Software  Reuse 

Software  reusability  is  widely  believed  to  be  a  key  to  improving  software 
development  productivity  and  quality  [Ref.  4],  It  also  has  the  most  potential  in  the  short 
term  to  show  tangible  benefits  in  a  number  of  domains  of  application.  It  allows  the 
developer  to  write  fewer  lines  of  code  and  to  spend  less  time  organizing.  To  date  the 
promise  offered  by  reusability  is  largely  unfulfilled.  Three  factors  that  now  make  it 
practical  to  formalize  a  model  of  reusable  software  [Ref.  2]  : 

1.  Maturation  of  the  software  industry  has  resulted  in  an  accepted  body  of  knowledge 
about  data  structures  and  algorithms. 

2.  A  number  of  software  engineering  principles  that  help  us  deal  with  the  problem  of 
developing  massive  software  intensive  systems  have  been  recognized. 

3.  The  development  of  Ada  a  language  that  offers  great  expressive  power,  is  tightly 
controlled  as  a  language,  and  demands  the  use  of  sound  software  engineering  practices. 

Research  in  this  area  centers  on  two  types  of  reusability  technologies:  composition 
technologies  and  generation  technologies.  In  composition  technologies  the  components 
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to  be  reused  are  largely  atomic,  and  ideally  unchanged  during  the  course  of  their  reuse. 
They  can  be  thought  of  as  building  blocks  that  are  combined  to  form  larger  programs  (the 
process  of  composition).  Generation  technologies  use  reusable  pattern  information  and 
weave  the  patterns  together  to  generate  new  code  [Ref.  4].  Other  problems  of  reuse 
receiving  a  great  deal  of  attention  are  the  classification  of  components  and  organization 
of  libraries  and  software  databases  so  that  needed  components  can  be  found  when  needed. 
These  latter  two  problems  which  are  the  focus  of  later  sections  of  this  thesis. 

C.  THE  COMPUTER  AIDED  PROTOTYPING  SYSTEM 

The  computer  aided  prototyping  system  is  an  integrated  environment  aimed  at 
rapidly  prototyping  hard  real-time  embedded  systems  [Ref.  5].  This  system  differs  in  its 
approach  from  most  other  prototyping  systems  in  its  approach  to  software  generation  from 
a  combination  of  translation  and  reuse  methods.  In  its  current  state  its  approach  to  reuse 
most  closely  resembles  the  composition  approach  described  in  the  previous  section. 
However,  the  system  also  has  a  translation  subsystem  which  is  used  to  generate  modules 
from  the  PSDL  specification.  Therefore  there  is  not  a  need  for  extremely  sophisticated 
composition  systems  which  rely  on  low  level  components  being  combined  into  higher 
level  program  units.  CAPS  instead  relies  on  the  software  base  component  to  reduce  the 
amount  of  work  required  of  the  prototyper  and  the  translator  by  storing  reusable 
components  that  are  known  to  be  efficient,  reliable  pieces  of  code  that  can  be  described 
using  the  prototyping  language.  These  components  may  be  at  any  level  of  detail,  and 
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represent  entire  subsystems  consisting  of  many  lines  of  code.  The  challenge  is  to 
organize  the  database  of  reusable  component  objects  in  a  manner  that  the  database  can 
be  queried  during  a  user  session,  using  only  the  information  available  in  the  PSDL 
description,  and  rapidly  return  a  matching  component  or  a  message  to  the  user  that  the 
component  is  not  available. 

CAPS  has  a  great  deal  of  potential  for  short  term  benefit.  Its  architecture  is  also 
ope.'  •  ough  that  it  can  take  advantage  of  the  results  of  emerging  technologies  in  many 
of  its  subsystems  with  minimum  disturbance  to  the  other  subsystems.  The  prototyping 
language  (PSDL)  is  a  relatively  small,  yet  powerful,  language  which  should  allow  the 
system  to  represent  constructs  in  many  domains.  Domains  can  be  described  by 
augmenting  PSDL  with  domain  specific  keywords.  This  feature  of  PSDL  has  not  been 
tested  in  any  previous  research.  This  thesis  presents  a  method  of  using  an  augmented 
form  of  PSDL  for  both  classification  and  retrieval  of  reusable  software  components. 

D.  GOALS  OF  THIS  THESIS 

The  goal  of  this  thesis  is  to  extend  the  current  conceptual  design  of  the  reusable 
software  component  base  to  more  adequately  meet  the  user’s  needs  in  the  CAPS 
prototyping  environment.  The  structure  of  the  objects  used  to  encapsulate  the  reusable 
components  is  detailed,  including  the  attributes  and  methods  which  may  be  needed  as  the 
CAPS  system  evolves.  Domain  analysis  is  incorporated  into  the  system  through  the 
augmentation  of  the  PSDL  language  with  keywords.  A  methodology  for  adding  new 


7 


classes  to  the  database  with  minimum  disturbance  of  the  existing  hierarchy  or  data  objects 
is  also  developed  in  this  thesis.  Finally,  a  new,  more  generalized,  method  for  searching 
the  database  based  on  some  simple  rules  stored  in  a  specialized  object  class  is  presented. 
The  final  design  of  the  software  base  presented  in  this  thesis  is  based  on  integrating 
features  of  domain  analysis,  object-oriented  databases,  knowledge  based  systems,  and 
language  specific  aspects  of  a  specific  programming  language,  in  this  case  Ada,  to  support 
a  prototyping  environment  using  a  higher  order  language,  in  this  case  PSDL.  The  focus 
is  on  the  processing  required  to  translate  a  PSDL  specification  into  a  database  query  in 
a  form  that  reduces  the  search  to  the  minimum  required  in  support  of  the  functional 
environment  identified  by  the  prototyper. 
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II.  BACKGROUND 


This  chapter  contains  material  on  the  development  of  an  effective  mechanism  for 
reuse  of  components  in  a  rapid  prototyping  environment  A  brief  discussion  of  the 
necessary  and  sufficient  conditions  for  reuse  is  followed  by  an  overview  of  some  of  the 
more  prominent  strategies  used  in  organization  of  libraries  and  databases  of  reusable 
components.  A  more  detailed  discussion  of  reuse  issues  can  be  found  in  previous  thesis 
work  by  Galik  [Ref.  6]  and  Steigerwald  [Ref.  7], the  CAMP  overview  document  [Ref.  1], 
and  various  other  articles  [Refs.  2,3].  The  major  types  of  software  generation 
environments  and  their  approaches  to  reuse  as  well  as  integration  mechanisms  are 
discussed  in  some  detail.  Since  the  major  area  of  concern  of  this  thesis  is  the  problem 
of  improving  and  more  effectively  integrating  reuse  into  the  CAPS  system  using  object- 
oriented  database  technology,  an  overview  of  object-oriented  concepts  and  databases,  the 
current  status  of  the  database  of  reusable  components  supporting  CAPS,  and  its  position 
in  the  overall  CAPS  environment  are  presented  here  as  well.  In  subsequent  chapters  the 
Prototyping  System  Description  Language  and  its  relation  to  the  Ada  language  is 
discussed.  PSDL  is  also  evaluated  for  its  potential  as  a  classification  and  retrieval 
language  for  reusable  Ada  components.  The  concepts  presented  here  will  be  used  in  this 
discussion. 
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A.  CONDITIONS  NECESSARY  FOR  EFFECTIVE  REUSE 

In  order  to  effectively  reuse  software  components  in  any  environment  there  are 
several  conditions  that  must  be  met.  These  operational  problems  fall  into  four  main  areas 
and  include  [Ref.  4:  p.  5]: 

1)  Finding  components 

2)  Understanding  components 

3)  Modifying  components 

4)  Composing  components 

In  this  thesis  the  focus  of  effort  is  on  finding  and  understanding  components.  Finding 
components  is  more  than  just  finding  an  exact  match.  It  includes  locating  highly  similar 
components.  It  includes  the  classification  of  components  included  in  the  software  base 
and  the  organization  of  these  components  in  a  order  to  aid  in  search  and  retrieval 
operations.  Understanding  components  is  primarily  a  documentation  issue.  But  the 
representation  of  descriptive  information  in  a  manner  that  can  be  useful  to  an  interactive 
user  is  of  concern  here.  Modification  and  composition  of  components  is  related  to  how 
components  become  parts  of  systems.  This  area  is  briefly  addressed  in  this  thesis.  CAPS 
can  support  these  operations.  Since  CAPS  is  a  prototyping  environment  rather  than  a 
production  environment  or  Software  Generation  System,  the  actual  production  of  code  is 
not  the  primary  objective  of  the  system.  As  CAPS  continues  to  evolve  these  areas  will 
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become  more  important  The  most  important  objective  of  the  Software  Base  Management 
System  is  the  identification  of  potentially  reusable  code.  Integration  of  the  reusable 
components  into  larger  systems  and  programs  is  handled  by  other  parts  of  the  CAPS 
system. 

B.  LIBRARY  CLASSIFICATION  SCHEMES 

Reuse  mechanisms  can  be  found  as  a  component  of  a  number  of  software 
development  environments.  The  most  basic  means  of  incorporating  reuse  into  a  software 
generation  system  is  through  the  use  of  libraries.  In  a  library  of  reusable  components  a 
group  of  software  components  that  support  particular  programming  functions  or  narrow 
domains  of  interest  are  placed  in  some  common  areas  that  are  easily  accessible  by  the 
programmer.  The  most  common  example  of  libraries  are  the  common  functions  found 
in  C  libraries,  and  narrowly  defined  domains,  such  as  math  libraries  in  C  and  Ada 
programming  environments.  These  libraries  are  very  useful,  but  have  a  major  drawback. 
These  simple  mechanisms  are  not  automatically  accessible  without  foreknowledge  of  their 
composition.  The  design  of  an  effective  reuse  system  must  allow  the  programmer  to 
identify  the  potentially  reusable  components  without  actually  knowing  of  their  existence. 
This  is  the  main  problem  addressed  in  the  design  of  classification  and  retrieval 
mechanisms. 

Two  schemes  of  classification  are  continually  mentioned  in  discussions  of 
organization  of  reusable  components.  The  most  commonly  mentioned  is  the  Booch 
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Taxonomy  of  Ada  components  [Ref.  2].  Booch  uses  a  descriptive  method  based  on  the 
form  of  the  component  including  information  on  the  abstraction  of  the  component  and  its 
time  and  space  properties  [Ref.  2:  p.  36],  His  method  is  very  useful  in  the  general 
categorization  of  components  into  their  basic  data  structure  related  types.  The  other 
method  of  classification  developed  by  Prieto-Diaz  takes  a  different  approach.  The  Prieto- 
Diaz  scheme  is  based  on  organizing  components  to  be  processed  using  the  relational 
database  model.  He  describes  a  tuple  of  six  attributes  that  can  be  used  to  categorize  any 
component.  Three  of  these  are  related  to  the  functionality  of  the  component  and  three 
related  to  the  environment  [Ref.  8:  pp.  280-281]. 

C.  INTEGRATION  OF  REUSE  INTO  ENVIRONMENTS 

Classification  and  organization  of  components  are  only  two  issues  related  to  the  use 
of  reusable  components  in  programming  environments.  There  must  also  be  some  means 
of  integrating  the  components  into  the  target  program  either  in  their  stored  form  or  in 
some  modified  form.  These  are  the  problems  of  understandability  and  modification 
addressed  earlier.  In  this  section  a  description  of  the  approaches  to  integration  of 
components  into  various  types  of  environments  is  presented. 

1.  Types  of  Reuse  in  Existing  Environments 

The  major  types  of  reuse  found  in  existing  programming  environments  are 
based  the  approaches  used  in  these  systems.  The  major  types  of  software  generation 
systems  in  use  today  are  based  on  either  the  generation  of  components  from  some  high 
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level  language  or  the  composition  of  existing  components  into  larger  programs  and 
systems.  Systems  using  the  generation  approach  attempt  to  generate  source  code  through 
the  transformation  of  some  higher  order  language  into  source  level  programming  language 
constructs  using  knowledge  based  techniques  to  control  the  transformation.  The  reuse  of 
transformation  information  stored  in  a  database  of  programming  knowledge  is  used  to 
accomplish  the  code  generation.  Systems  developed  using  this  approach  have  thus  far 
been  inefficient  and  inadequate  to  the  needs  of  embedded  and  hard  real-time  programs. 

But  there  is  a  great  deal  of  ongoing  research  in  this  area  and  it  is  generally 
acknowledged  that  generation  based  systems  are  the  systems  of  the  future  [Ref.  3]. 

Systems  that  have  the  most  short  term  potential  benefit  are  composition  based. 
Systems  developed  using  the  composition  approach  attempt  to  identify  source  components 
and  combine  them  into  larger  programs.  Identification  and  integration  can  be  guided  by 
programs  that  access  the  database  or  by  knowledge  based  techniques.  These  systems  can 
store  multiple  versions  of  the  same  component  and  can  generate  much  more  efficient 
systems.  However  the  problem  is  how  to  decide  the  level  of  abstraction  for  the  individual 
components.  Storage  of  large  subsystems  can  provide  gains  in  productivity  at  the  cost 
of  overall  program  efficiency.  Using  large  subsystems  can  result  in  the  incorporation  of 
unused  code  into  a  program.  Using  small  components  is  acceptable  for  small  programs, 
but  the  problem  of  how  to  find  components  in  a  large  database  of  very  small  components 
and  combine  them  is  much  more  complex.  The  programmer  needs  to  understand  more 
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about  the  details  of  the  software  base  in  order  to  adequately  specify  needed  components. 
The  database  designer  has  the  problem  of  designing  efficient  methods  for  search,  selection 
and  combination  of  the  components.  Another  drawback  of  composition  based  systems 
in  general  is  the  lack  of  any  means  of  building  components  from  scratch.  If  the 
component  is  not  in  the  library  or  database  it  provides  only  a  message  to  the  user. 

2.  Domain  Analysis 

Another  approach  to  the  organization  and  integration  of  reusable  components 
into  a  software  generation  system  is  to  organize  the  reuse  effort  around  the  projected 
application  area  or  domain  of  interest.  Using  a  process  known  as  domain  analysis  [Refs. 
1,8,9]  the  application  area  is  broken  down  into  the  categories  of  subprograms  or  program 
objects  needed  to  implement  needed  functions  and  structures  for  parts  of  a  system.  A 
domain  analysis  involves  an  intensive  study  of  the  application  area  and  previous  software 
development  efforts  [Ref.  1:  p.  7].  Products  of  the  domain  analysis  may  include  parts 
taxonomies  or  classification  schemes  for  storing  reusable  components  in  databases, 
domain  languages  for  specifying  software  components,  transformation  rules  used  for 
generating  components  from  the  specifications,  and  rules  for  composing  subsystems  from 
combinations  of  smaller  software  components.  This  is  the  approach  used  in  Draco  and 
the  CAMP  project.  A  more  detailed  summary  of  the  process  used  by  these  two  methods 
and  the  products  of  domain  analysis  in  each  of  these  systems  is  described  in  the  following 
sections. 
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a.  The  Draco  methodology 

The  Draco  method  involves  the  analysis  of  an  application  area,  or  domain, 
in  order  to  identify  and  codify  the  reusable  concepts  or  objects,  and  models  into  a  domain 
language  that  can  be  interpreted  by  the  Draco  system  and  used  in  the  generation  of  code. 
The  Draco  method  uses  three  analysts:  an  application  domain  analyst,  a  domain  designer, 
and  a  modeling  domain  analyst.  The  application  domain  analyst  examines  the  needs  and 
requirements  of  systems  in  come  common  application  domain,  identifying  the  objects  and 
operations  that  are  germane  to  an  area  of  interest.  Once  identified  this  is  given  to  the 
domain  designer  who  specifies  the  objects  and  operations  in  a  manner  known  to  the  Draco 
system.  The  modeling  domain  analyst  is  concerned  with  the  methods  used  to  model 
domains  in  Draco.  The  primary  concern  is  to  insure  that  the  system  does  not  duplicate 
existing  domain  descriptions  when  describing  new  domains.[Ref.  4:  p.  302] 

The  end  result  of  the  analysis  is  a  domain  description  of  a  particular  domain  in  a 
language  that  can  interpreted  by  the  Draco  system.  The  Draco  system  is  a  tool  that 
combines  generation  and  composition  approaches  by  successively  transforming  statements 
of  the  component  specification  in  the  domain  language.  Statements  in  the  domain 
language  are  parsed  into  internal  form  and  may  be  [Ref.  4:  pp.  306-307]: 

1.  prettyprinted  back  into  the  external  syntax  of  the  domain; 

2.  optimized  into  a  statement  in  the  same  domain  language; 
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3.  taken  as  an  input  to  a  program  generator  that  restates  the  problem  in  the  same 
domain; 

4.  analyzed  for  possible  leads  for  optimization,  generation.or  refinement;  or 

5.  implemented  by  software  components,  each  of  which  contains  multiple 
refinements  and  which  make  implementation  decisions  by  restating  problem  in 
other  domain  languages. 

The  Draco  system  recognizes  the  use  of  actual  source  code  as  valuable  to  short  term 
productivity  but  is  oriented  toward  generation  technologies  as  the  long  term  solution  [Ref. 
4:  p.  316].  However  they  do  recognize  the  need  for  analysis  at  the  major  subsystem  level 
as  a  means  of  constraining  and  smoothing  the  modelling  process,  particularly  in  the  early 
stages  of  design.  The  reuse  of  design  and  modelling  information  that  may  still  be 
modified  prior  to  the  production  of  actual  code  is  limited  to  subsystems  that  are  already 
known,  or  previously  developed  and  stored  in  Draco  [Ref.  4:  pp.  315-316]. 

b.  The  CAMP  methodology. 

One  of  the  objectives  of  the  CAMP  project  was  to  evaluate  the  utility  of 
source  code  reuse  to  the  maximum  extent.  Their  domain  analysis  was  oriented  toward 
the  identification  of  the  areas  of  missile  software  systems  that  had  commonality.  They 
did  this  by  studying  ten  previously  developed  missile  related  software  systems.  The  result 
of  this  domain  analysis  and  commonality  study  was  the  identification  of  seven  major 
areas  in  the  domain  of  interest.  Within  these  areas  a  total  of  21  categories  of  components 
were  developed.  The  CAMP  parts  taxonomy  is  based  on  classifying  components  into 
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these  21  categories.  The  taxonomy  is  shown  in  Figure  2.1  [Ref.  1].  The  category  of  each 
part  is  an  attribute  in  the  database  of  CAMP  parts  which  was  developed  using  Oracle, 
another  package  using  the  relational  model. 


DATA  PACKAGE  PARTS 
-Data  Constanta 

;■ -bat  a  Type  a  -  < 

EQUIPMENT  INTERFACE  PARTS 
-General  Purpose 
-Specific  Equipment 

PRIMARY  OPERATION  PARTS 
-Navigation 
-Kalman  Filter 
-Guidance  and  Control 
-Non-Guidance  Cont  rol 

ABSTRACT  MECHANISM  PARTS 
-Abstract  oata  structures 
^•Abstract  Processes 


PROCESS  MANAGEMENT  PARTS 
-Asynchronous  cont role 
-Communications 

MATHEMATICAL  PARTS 
-Coordinate  Algebra 
-Matrix  Algebra 
-Quaternion  Algebra 
-Trigonometric 
-Data  Conversion 
-Signal  Processing 
-Polynimials 
-General  Math 

GENERAL  UTILITY  PARTS 


Figure  2.1  The  CAMP  Parts  Taxonomy. 

Parts  that  were  developed  under  the  CAMP  project  were  largely  source  code  using 


the  Ada  generic  package  capability,  some  specific  data  types  and  operations  common  to 


the  majority  of  the  systems  studied,  and  schematic  parts,  or  templates  that  can  be  called 
up  and  customized  by  user.  The  CAMP  approach  is  oriented  toward  composing  systems 
by  retrieving  parts  from  a  software  base  and  combining  them  into  systems  or  subsystems. 
The  composition  uses  an  expert  system  containing  database  search  rules  and  combination 
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rules  for  the  individual  components  and  rules  for  combining  components  into 
subprograms.  More  detail  on  CAMP  is  presented  in  Appendix  A. 

D.  AN  IDEAL  SOFTWARE  GENERATION  SYSTEM 

In  previous  sections  the  two  general  categories  of  software  generation  systems  were 
described.  There  arc  some  obvious  tradeoffs  made  when  building  a  system  using  either 
approach.  An  ideal  system  would  include  both  of  these  approaches  allowing  for  the 
combination  of  the  benefits  of  each.  There  would  be  components  of  this  system  that 
would  be  able  to  combine  reusable  source  level  components  as  well  as  generation 
components  used  to  build  new  components  by  transforming  specifications.  The  structure 
of  such  a  system  was  described  by  the  CAMP  project  developers  and  is  shown  in  Figure 
2.2  [Ref.  1:  p.  50]. 

The  ideal  system  would  je  controlled  by  an  expen  system  containing  both 
application  domain  and  programming  knowledge  It  would  have  database  and  knowledge 
base  components.  And  it  would  have  the  capability  to  generate  software  from  an  input 
requirement  through  either,  or  a  combination  of  generation  and  composition  techniques. 
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Figure  2.2  An  Ideal  Software  Generation  System 


E.  THE  COMPUTER  AIDED  PROTOTYPING  SYSTEM  ENVIRONMENT 

The  Computer  Aided  Prototyping  System  (CAPS)  is  a  tool  which  is  being  developed 
to  support  software  development  through  the  implementation  of  a  rapid  prototyping 
methodology  [Refs.  10,1 1].  CAPS  is  designed  to  aid  the  software  designer  in  the  analysis 
of  hard,  real-time  systems  using  specifications  and  reusable  software  components  to 
automate  the  rapid  prototyping  process.  It  uses  a  high  level  prototyping  language  called 
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the  Prototyping  System  Descriptive  Language  (PSDL)  [Ref.  12].  Its  major  goals  are  to 
decrease  the  development  time  and  increase  the  quality  of  production  code  by  iteratively 
prototyping  the  system  and/or  key  subsystems  until  the  requirements  and  specifications 
needed  to  build  the  production  system  are  firm.  The  major  components  of  the  system  are 
shown  in  Figure  2.3  [Ref.  6:  p.9]. 

As  previously  mentioned,  software  generation  is  not  the  primary  goal  of  CAPS. 
However  the  identification  of  reusable  software  components  can  greatly  aid  in  both  the 
reduction  of  development  time  and  accuracy  goals  of  CAPS.  CAPS  reusable  components 
are  stored  as  objects  representing  the  encapsulation  of  various  programming  structures 


Figure  2.3  The  Computer  Aided  Prototyping  System 


which  are  of  use  to  the  designer  in  choosing  the  data  types  and  operations  needed  to 
implement  programs  in  the  given  application  domain.  The  software  base  component  is 
currendy  implemented  as  a  collection  of  Ada  related  objects  stored  in  an  object-oriented 
database.  Actual  Ada  source  code  is  an  attribute  of  the  stored  object  as  well  as  other 
information  needed  for  matching  PSDL  descriptions  to  corresponding  Ada 
implementations.  For  any  given  domain  the  number  of  objects  which  may  be  stored  is 
large.  The  current  database  organization  is  shown  in  Figure  2.4  [Ref.  6].  It  provides  for 
only  two  classes,  or  groupings  of  objects.  This  makes  the  problem  of  Finding  objects  a 
very  long  and  difficult  one.  This  thesis  concentrates  on  ways  to  improve  the  organization 
of  the  database  to  support  identification  and  retrieval  of  reusable  objects. 


Figure  2.4  The  Current  Software  Base  Organization 
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F.  OBJECT-ORIENTED  DATABASES 


Object-oriented  databases  have  become  increasingly  popular  as  an  element  of  design 
environments.  The  object  oriented  paradigm  has  shown  particular  promise  in  the  area  of 
computer  assisted  design  and  manufacturing  environments  (CAD/CAM)  [Ref.  13]. 
Object-oriented  databases  are  also  becoming  more  common  as  components  of  software 
development  environments.  Therefore  it  is  appropriate  to  discuss  this  area  in  some  detail. 
The  following  discussion  of  object-oriented  concepts  further  justifies  the  continued 
inclusion  of  this  type  of  database  for  the  Software  Base  Management  System  of  CAPS. 

1.  Object-Oriented  Concepts 

Before  explaining  the  object-oriented  database  in  more  detail  a  brief  review 
of  object-oriented  concepts  is  required.  One  accepted  definition  of  object-oriented  is 
[Ref.  14]: 

object-oriented  =  objects  +  classes  +  inheritance 
The  concept  of  an  object  is  based  on  the  principles  of  data  abstraction  and  information 
hiding  [Ref  15:  p.  2],  Data  abstraction  represents  a  system  as  a  set  of  objects  and  the  set 
of  operations  characterizing  the  behavior  of  the  objects  [Ref.  15:  p.  2].  Information 
hiding  decomposes  a  system  into  components,  each  characterized  by  knowledge  of  a 
design  decision  hidden  from  all  others  [Ref.  15:  p.  3].  Classes  are  templates  from  which 
individual  instances  of  objects  may  be  created  by  "create"  or  "new"  operations.  Classes 
are  organized  in  hierarchies  to  facilitate  the  inheritance  of  attributes  and  methods  used  by 
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that  class.  Inheritance  is  a  mechanism  which  allows  a  class  to  inherit  operations  from 
superclasses  and  also  allows  subclasses  of  the  class  to  inherit  its  operations  [Ref.  14], 
Theoretically  a  given  class  of  objects  may  have  many  subclasses  or  superclasses. 
However,  practically,  most  languages  implementing  object-oriented  concepts  organize  the 
class  structure  into  a  hierarchy  using  only  single  inheritance.  An  object  of  a  given  class 
may  have  many  subclasses,  but  only  one  directly  connected  superclass. 

Object-oriented  approaches  were  first  used  as  a  means  of  exploiting  encapsulation. 
Encapsulation  is  necessary  to  ease  the  development  and  maintenance  of  larger  systems 
by  decomposing  the  larger  system  into  smaller  encapsulated  subsystems.  Typically,  the 
encapsulated  subsystems  are  thought  of  in  terms  of  "objects"  rather  than  "programs"  and 
"data"  [Ref  15:  pp.  3-4].  You  adopt  a  particular  object  model  and  then  encapsulate 
objects  in  terms  of  a  visible  interface,  called  operations,  while  hiding  the  object’s 
implementations  and  data  structures.  Just  how  object-oriented  languages  provide 
constructs  for  defining  useful  kinds  of  objects  can  be  discovered  in  an  analysis  of  the 
issues  of  software  reusability.  Reusability  of  programming  objects  is  supported  by  the 
packaging  of  objects  in  such  a  way  that  they  can  be  conveniently  reused  without 
modification  to  solve  new  problems  [Ref.  15:  p.  5]. 

Object-oriented  development  is  the  use  of  object-oriented  concepts  in  the  analysis, 
design,  and  implementation  of  software  systems  [Ref.  15:  p.  3].  Object-oriented 
development  leads  to  architectures  that  are  based  on  systems  manipulating  objects.  Rather 
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than  concentrate  on  what  the  system  does,  using  this  method  of  development  the 
concentration  is  on  what  the  parts  of  the  system  do  or  have  done  to  them  by  other  parts 
[Ref.  14]. 


2.  The  Class  Hierarchy  of  Objects 

In  object-oriented  programming  one  of  the  main  advantages  is  the  ability  to 
reuse  existing  attributes  and  methods  defined  for  a  given  class  of  objects  in  the  subclasses 
of  that  object.  Often  the  definition  of  new  object  classes  is  accomplished  by  refinement 
or  specialization  of  already  existing  classes.  The  newly  defined  object  class  inherits  all 
or  many  of  the  characteristics  (attributes  and  methods)  of  its  superclass  and  may  either 
add  or  refine  methods  in  its  own  definition.  A  sample  inheritance  hierarchy  is  shown  in 
Figure  2.5  [Ref.  15]. 


In  this  example  the  entire  hierarchy  is  based  on  the  specialization  of  the  objects  by  adding 
more  detail  as  we  go  down  the  hierarchy.  The  objects  at  the  lower  levels  inherit  all  of 
the  characteristics  of  the  higher  levels.  But  the  characteristics  of  the  more  general 
superclasses  remain  available  to,  or  are  inherited  by,  the  more  specialized  object  classes. 
This  is  the  idea  of  the  "is-a"  relationship  used  as  the  basis  for  classification  in  object- 
oriented  systems.  The  Ship  is-a  public  vehicle,  that  is,  it  is  a  specialization  of  the  public 
vehicle  class.  It  has  all  the  characteristics  of  the  public  vehicle  plus  other  specialized 
characteristics  that  distinguish  it  from  its  more  general  superclass. 

3.  Object-Oriented  Programming  and  Rapid  Prototyping 

As  previously  described,  object-oriented  programming  methodologies 
concentrate  on  the  use  of  inheritance  for  code  reuse  between  objects  within  the  same  parts 
of  a  hierarchy.  They  also  focus  on  the  use  of  encapsulation  to  insure  that  individual 
objects  are  as  independent  as  possible.  It  is  this  second  aspect  that  is  the  most  important 
in  the  context  we  are  discussing.  In  the  general  case,  a  program  or  program  module  can 
be  described  as  an  entity  (object)  that  has  some  input  and  output,  and  performs  some 
transformation.  This  description  of  a  program  module  can  form  the  basis  for 
encapsulating  ideas,  or  threads,  that  an  individual  program  module  represents.  If  this 
approach  is  taken  throughout  the  design  of  a  software  system,  the  successive  iterations 
of  problem  decomposition  eventually  form  objects  at  a  very  low  level,  which  capture 
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small  subsets  of  the  overall  requirement  into  individual  entities  (objects).  Thus  an  object 
may  be  represented  by  the  function  it  performs. 

4.  A  Database  of  Objects  to  Support  Rapid  Prototyping 

With  these  basic  definitions  in  mind,  how  do  we  merge  the  concepts  of  OOP 
languages  with  database  management  technology  and  rapid  prototyping?  Galik  lists  some 
of  the  more  significant  properties  of  an  OODBMS  [Ref.  6],  These  include  persistency, 
active  data,  extensibility,  and  abstraction.  He  points  out  that  data  objects  must  be  "non¬ 
volatile"  while  maintained  within  the  database  [Ref.  6:  p.  301.  A  database  requires  that 
the  persistence  of  its  data  "transcend"  that  of  individual  programs  which  may  have  a 
"short"  lifetime.  Since  objects  "persist"  between  execution  of  operations  they  should 
provide  a  better  starting  point  for  databases  [Ref.  14].  The  object-oriented  database  of 
components  used  in  CAPS  can  be  thought  of  as  a  persistent  entity  in  its  own  right.  The 
components  that  make  up  the  database  are  only  a  portion  of  what  we  must  consider  when 
comparing  this  form  of  database  with  other  database  models.  Additionally,  we  must 
consider  the  standard  database  functions  which  the  OODBMS  must  provide.  These 
functions  include  concurrency  control,  recovery,  transaction  management,  and  security 
found  in  all  types  of  databases  [Ref.  6:  p.  30]. 

OODBMSs  have  many  of  the  features  necessary  to  aid  in  the  retrieval  and  use  of 
complex  data  applications  that  are  particular  to  computer  aided  prototyping.  The 
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following  are  some  of  the  features  identified  in  OODBMSs  as  aiding  in  rapid  prototyping 
[Ref.  13:  pp.  32-35]: 

a.  Increased  modeling  power  over  relational  models.  Relational  models  have 
trouble  forcing  real-world  objects  into  fixed  programming  constructs  and  are  often 
inadequate  to  store  complex  info. 

b.  A  set  of  predefined  system  types  (such  as  set,  queue,  stack,  and  list).  Avoids 
cluttering  the  solution  with  data  specific  routines. 

c.  Stores  the  data  structure  (object)  directly  on  the  disk.  Avoids  extra  code  required 
for  loading  and  mapping  disk  information  to  the  usual  memory  data  structures  if  the 
language  supports  object  persistence. 

d.  Enforces  data  abstraction  and  data  hiding.  The  programmer  needs  only  to  know 
what  the  objects  do. 

e.  Supports  code  reusability.  The  programmer  can  write  less  code  while  implementing 
the  same  functionality. 

f.  "Triggers"  modules  to  allow  programmers  to  combine  them  as  needed.  It  is  hard 
to  make  code  generic  enough  to  achieve  the  same  effect  without  objects. 

g.  Allows  generic  programming  through  polymorphism  and  meta-information. 
Polymorphism  takes  the  parameters  passed  and  automatically  dispatches  a  call  to  the 
correct  routine  called.  Meta-information  alleviates  the  need  to  hard-code  user-defined 
types  in  the  program. 

The  following  may  be  considered  drawbacks  of  an  OODBMS: 

a.  A  long  learning  curve  is  associated  with  learning  object  programming. 

b.  Robust  and  reliable  tools,  such  as  source-level  debuggers  and  fast  compilers,  are 
not  readily  available. 

c.  Without  implementation  level  knowledge,  a  programmer  may  not  recognize  a  bug 
hidden  through  abstraction. 


d.  Since  semantic  information  is  also  stored  with  the  object,  it  may  require  more 
storage  space  than  regular  file  based  systems. 

e.  Strict  type  checking  causes  compile  time  performance  to  be  worse  than  in  other 
database  management  systems. 


G.  DATABASE  SUPPORT  OF  CAPS 

The  CAPS  environment  is  oriented  toward  the  development  of  programs  using  an 
object-oriented  approach  that  will  be  implemented  using  a  conventional  programming 
language,  in  this  case  Ada.  Conventional  programming  languages  have  constructs  that 
are  used  in  implementing  modules,  that  also  have  their  own  descriptions  (functions  and 
procedures,  for  exam  .  This  programming  language  information  may  also  be  useful 
in  designing  indr,  *aual  objects  in  the  manner  described  above.  But  to  effectively  reuse 
objects  designed  using  conventional  programming  languages  there  are  other  issues  that 
must  be  addressed.  One  of  the  more  important  is  how  to  store  the  objects  for  easy 
retrieval.  This  is  the  area  of  classification.  One  of  the  goals  of  building  programs  from 
encapsulated  modules  of  code  is  to  reuse  code  previously  used  in  the  program,  or  in 
similar  programs  developed  in  the  past.  This  is  where  the  use  of  object-oriented 
databases  of  reusable  software  components  comes  into  the  development  process.  The 
classification  of  reusable  components  into  a  hierarchy  based  on  specialization  of  the 
component  object  classes  and  methods  provides  the  needed  indexing  information  as  well 
as  a  code  sharing  (inheritance)  capability  for  methods  needed  to  use  the  objects. 
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Information  presented  in  this  chapter  provides  the  needed  guidelines  for  defining 
the  structure  of  an  object  hierarchy  of  reusable  components  to  support  the  CAPS  system. 
Other  parts  of  the  CAPS  system  provide  the  aggregate  constructor,  or  composition 
mechanism,  needed  to  combine  objects  stored  in  the  database  into  larger  programs.  Using 
the  guidelines  described  in  this  chapter  a  proposed  hierarchy  of  reusable  components  is 
developed  and  the  needed  attributes  and  methods  for  the  objects  are  identified. 


in.  PSDL  AND  THE  CAPS  ENVIRONMENT 


In  this  chapter  the  Prototyping  System  Description  Language  (PSDL)  is  evaluated 
for  its  effectiveness  and  potential  as  a  classification  and  retrieval  language  for  the 
Software  Base  Management  System.  The  Computer  Aided  Prototyping  System  is 
described  in  some  detail  to  show  the  interactions  between  the  system  components, 
particularly  those  that  interface  with  the  Software  Base  Management  System.  A  much 
more  detailed  description  of  this  latter  area  is  contained  in  [Ref.  5].  PSDL  is  extensively 
covered  by  [Refs.  12,16]. 

The  focus  of  this  chapter  is  on  the  development  of  an  effective  mechanism  for 
organizing  the  software  base  using  concepts  supported  by  PSDL.  We  outline  a 
classification  scheme  for  storing  components  in  the  software  base  and  the  requirements 
for  processing  PSDL  specifications  into  a  form  that  can  be  used  to  query  the  database. 
This  is  followed  by  a  discussion  of  a  method  of  deriving  a  class  hierarchy  using  PSDL 
constructs  and  the  results  of  the  domain  analysis.  Finally  the  problem  of  finding 
components  in  the  class  hierarchy  is  addressed  through  the  development  of  some  simple 
access  rules  used  as  a  front  end  to  the  database.  Pre-processing  these  rules  narrows  the 
search  of  the  database. 
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A.  PSDL  AS  A  CLASSIFICATION  LANGUAGE 


PSDL  holds  a  great  deal  of  promise  as  a  classification  and  retrieval  language  for 
accessing  the  object  oriented  database  of  reusable  components.  It  is  a  small,  yet 
powerful,  language  and  is  very  compatible  in  its  method  of  specification  with  that  of  the 
Ada  language.  It  can  also  be  customized,  through  its  keyword  capability,  to  represent  the 
domains  of  interest  covered  by  the  software  base.  Appendix  B  contains  the  current 
version  of  the  basic  PSDL  grammar.  In  the  following  sections  the  use  of  PSDL 
specifications  to  represent  component  specifications  is  discussed  with  particular  emphasis 
on  the  detail  that  is  possible  using  basic  PSDL  augmented  with  a  few  keywords  derived 
from  a  sample  domain  analysis. 

1.  Mapping  PSDL  Descriptions  to  Ada  source  code. 

A  PSDL  description  of  a  component  involves  two  main  parts:  a 
SPECIFICATION  and  an  IMPLEMENTATION.  The  SPECIFICATION  part  describes 
component  attributes  including  the  component  type,  either  OPERATOR  or  TYPE,  INPUT 
and  OUTPUT  variables,  and  information  on  requirements  and  constraints.  The 
SPECIFICATION  part  contains  much  of  the  information  seen  in  the  specification  portion 
of  an  Ada  implementation  of  the  part.  A  sample  PSDL  description  with  a  corresponding 
implementation  is  shown  in  Figures  3.1  and  3.2.  There  are  several  areas  of  commonality 
between  a  PSDL  specification  and  an  Ada  component  used  to  implement  the  specification. 
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PSDL  DESCRIPTION 


OPERATOR  controller_start_up 

SPECIFICATION 

INPUT  control_panel:  real,  sensor_input:  real 
OUTPUT  missiIe_control:  real 
MAXIMUM  EXECUTION  TIME  90ms 
BY  REQUIREMENTS  control_panel_max 

DESCRIPTION 

{  Extracts  the  control  panel  input  and  sensor  input  and 
uses  them  to  calculate  the  control  signal  for  the  missile. 

} 

END 


Figure  3.1  Sample  PSDL  Component  Description. 


-ADA  IMPLEMENTATION  OF  CONTROLLER  ST ART  UP 

WITH  weapons_controller_package; 

USE  weapons_controller_package; 

PROCEDURE  controller_start_up(control_pane!, 

sensor_input:  IN  float; 
missile_control:  OUT  float)is 

enable_signal:  real; 

BEGIN 

enable_signal:=calculate_control(control_panel, 

sensor_input); 

missile_control:=  enable_signal; 

END  controller  start_up 

Figure  3.2  Sample  Implementation  of  Figure  3.1 
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These  areas  can  be  useful  in  choosing  reusable  implementations  meeting  the  requirements 
described  in  a  PSDL  description.  The  most  obvious  areas  of  commonality  are  the  direct 
mapping  of  the  types  used  in  the  specification  and  the  implementation.  The  requirements 
information  stored  in  the  component  specification  is  useful  as  it  may  be  possible  to 
identify  other  needed  components  from  information  contained  in  the  requirements.  In  this 
case  the  reference  to  the  control_panel_max  requirement  is  handled  by  the 
weapons_controller_package.  This  package  is  referenced  using  the  Ada  WITH  and  USE 
capabilities  in  the  implementation  of  the  component.  The  MAXIMUM  EXECUTION 
TIME  specified  may  also  be  useful  in  choosing  between  possible  implementations  of  this 
component  having  the  same  name  and  capabilities,  but  different  timing  properties.  The 
information  in  the  DESCRIPTION  portion  of  the  specification  may  be  useful  to  the  user 
of  a  browsing  system  for  discriminating  between  components  by  matching  the 
DESCRIPTION  used  in  the  PSDL  component  with  documentation  representing  the 
functionality  of  actual  components. 

2.  Using  PSDL  to  classify  components 

PSDL  has  several  constructs  included  in  the  language  that  are  useful  for 
grouping  components.  The  areas  that  are  important  in  the  use  of  PSDL  to  classify  objects 
are  the  ability  to  classify  objects  as  either  OPERATORS  or  TYPEs,  the  INPUT  and 
OUTPUT  types,  and  whether  or  not  a  component  has  or  retains  STATE  (is  a  state 
machine).  The  types  of  the  INPUT  and  OUTPUT  variables  used  in  the  OPERATOR 
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components  must  also  be  defined  as  TYPE  components  in  the  TYPE  part  of  the  software 
base.  If  a  component  has  states  it  must  be  represented  by  an  abstract  state  machine 
component,  which  corresponds  to  the  machine  type  of  operator  in  PSDL  or  an  Ada 
package  [Ref.  17]. 

The  KEYWORD  capability  provided  by  PSDL  is  also  very  useful  in  the 
classification  of  Ada  components  for  inclusion  in  the  software  base.  The  KEYWORD 
is  a  capability  of  PSDL  that  allows  augmentation  by  the  user.  When  used  in  the 
component  classification  and  retrieval  processes  described  in  later  sections,  KEYWORDS 
represent  the  major  domains  of  interest.  The  definition  of  KEYWORDS  to  be  used  in  a 
given  database  of  components  is  analogous  to  the  development  of  the  domain  language 
used  in  the  Draco  system  mentioned  earlier.  In  combination  with  the  structures  that 
PSDL  can  describe  in  its  basic  form  a  classification  scheme  can  be  derived  that  will 
greatly  aid  the  user  of  the  software  base. 

3.  The  Generalization  Lattice  Structure 

The  previous  section  described  some  of  the  more  useful  information  provided 
in  the  PSDL  specification  of  a  component.  The  problem  now  is  how  to  use  this 
information  to  form  a  classification  scheme  for  reusable  components.  The  classification 
scheme  used  for  the  software  base  must  meet  several  requirements  to  be  useful  to  the 
prototyper.  It  must  be  easily  extensible  to  allow  evolutionary  growth  of  the  available 
components.  The  user  should  be  able  to  browse  available  components  and  select  and 
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retrieve  components  efficiently.  [Ref.  12:  p.  70]  To  support  these  operations  the  software 
base  organization  must  be  able  to  organize  components  in  relatively  small,  yet  distinct 
classes.  Since  the  goal  of  the  system  is  to  support  the  overall  process  of  CAPS 
development  this  organization  should  be  largely  transparent  to  the  user.  It  must  take  into 
consideration  the  implementation  language  as  well.  What  follows  is  a  description  of  a 
classification  scheme  that  meets  these  requirements  for  the  OPERATOR  type  of 
component 

In  order  to  meet  these  goals  a  classification  scheme  based  on  categories  of 
information  that  can  be  derived  from  information  provided  in  the  Specification  portion 
of  the  PSDL  description  is  used.  A  process  known  as  generalization  by  category  is  useful 
in  describing  the  categories  of  components  found  in  the  software  base  [Ref.  10],  The 
OPERATOR  type  of  component  is  particularly  suited  to  this  approach.  An  OPERATOR 
in  PSDL  can  be  a  machine  or  a  function,  depending  on  whether  it  has  state. 
Implementations  of  OPERATORS  in  the  software  base  may  be  generic  components  or 
specific  pieces  of  source  code  representing  the  major  building  blocks  available  in  Ada: 
the  package,  procedure,  function,  or  task.  For  these  specific  implementations  we  assume 
that  the  types  that  appear  in  the  specifications  of  these  Ada  units  are  restricted  to  types 
already  known  to  the  software  base  management  system  and  stored  in  the  SPECIFIC 
TYPE  portion  of  the  software  base.  A  check  of  the  specification  can  determine  if  the 
PSDL  component  uses  these  types.  If  so  it  belongs  to  the  category  of  components  that 
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may  have  exact  implementations  in  the  software  base.  Otherwise,  the  component  is 
generic.  Similarly,  if  the  component  has  STATE  it  belongs  to  the  category  corresponding 
to  the  machine  type  of  PSDL  operator. 


The  categories  mentioned  above  are  valid  for  all  operators  in  the  software  base. 
Additionally  these  categories  may  be  combined  to  form  a  lattice  structure  that  further 
subdivides  the  OPERATOR  side  of  the  hierarchy  into  four  distinct  classifications  based 


on  only  the  analysis  of  the  basic  PSDL  structure.  This  lattice  is  shown  in  Figure  3.3. 


Figure  3J  The  generalization  lattice  of  categorical  properties  available  in  a 
basic  PSDL  Specification 
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The  lattice  allows  the  specialization  of  OPERATOR  components  into  four  classes 
which  can  easily  be  described  and  differentiated  using  apriori  analysis  of  the  component’s 
PSDL  specification.  While  this  is  an  improvement  on  the  current  classification  scheme 
[Ref.  6]  there  is  still  the  problem  of  finding  a  way  to  further  reduce  the  number  of 
potential  components  in  each  class.  The  lattice  provides  only  a  partial  solution. 
However,  adding  an  additional  dimension  of  domain  description  through  the  use  of  the 
KEYWORD  in  PSDL  can  improve  classification  scheme  even  further.  An  example  is 
shown  in  Figure  3.4: 


COMPONENT 


naci.oii  rue. Oil  kacs.sp  risc.sp  kaci.oii  rric.ori  kacs.sp  usc.sp 


■  AC  1 .0  K  I  •  OKSCIIC  IACIIII  PA  ITS 

■  AC1.SP  •  StlCIPIC  I  AC  1 1 1 1  PA  ITS 
PSIC.OSS  •  0I1I1IC  rilCTIOS  PASTS 
rssc.sp  •  spicinc  pisctios  paits 


Figure  3.4  OPERATOR  classification  with  addition  of  Domain  information. 


37 


We  see  that  the  number  of  available  classes  has  been  increased  significantly  from 
the  original  single  OPERATOR  class.  This  has  been  done  in  an  orderly  fashion  by  taking 
advantage  of  only  the  basic  PSDL  language  augmented  by  an  arbitrary  number  of  domain 
related  keywords.  This  type  of  classification  scheme  would  be  adequate  for  many  library 
type  of  implementations.  But  it  still  does  not  take  full  advantage  of  the  capabilities  of 
object-oriented  databases.  The  next  section  further  refines  the  classification  scheme  to  take 
advantage  of  the  object-oriented  model. 

4.  The  class  hierarchy  of  components 

In  order  to  effectively  organize  an  object-oriented  database  more  than  just  the 
categories  of  objects  must  be  considered.  The  previous  section  showed  that  PSDL 
augmented  by  a  domain  language  of  KEYWORDS  provides  an  effective  means  of 
organizing  domain  related  components  into  useful  PSDL  related  objects.  However  the 
methods  required  to  incorporate  the  components  into  the  prototype  were  not  considered. 
As  previously  mentioned,  one  of  the  advantages  of  the  object-oriented  model  is  the  ability 
to  inherit  attributes  and  methods  down  the  class  hierarchy.  The  inheritance  of  attributes 
allows  the  definition  of  attributes  for  the  entire  OPERATOR  hierarchy  at  the  OPERATOR 
class  level  and  the  inheritance  of  the  attribute  definitions  unchanged  throughout  the 
OPERATOR  side  of  the  hierarchy.  The  inheritance  of  methods  problem  is  different. 

The  software  base  management  system  currently  uses  Ada  as  the  target  language 
for  source  code  portions  of  the  code  related  objects.  One  of  the  parts  of  the  Ada 
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language  that  is  very  supportive  of  reuse  is  the  generic  facility  [Refs.  2,16].  Instantiation 
of  Ada  generic  packages  and  subprograms  allows  the  multiple  reuse  of  the  same  source 
code  within  the  same  program.  The  instantiation  method  for  the  generic  classes,  is 
different  than  that  used  by  the  specific  classes.  The  problem  with  implementing  these 
methods  using  the  previously  described  hierarchy  is  that  there  would  have  to  be  a  specific 
method  attached  to  each  class  in  the  hierarchy.  This  makes  inheritance  of  methods 
useless  to  us  in  the  design  of  the  object-oriented  database  and  greatly  increases  the 
programming  load.  A  better  solution  is  to  look  at  the  problem  of  classifying  objects  as 
either  generic  or  specific  implementations  first,  and  then  incorporating  the  domain 
information.  The  modified  hienrchy  using  this  method  of  classification  is  presented  in 
Figure  3.5.  The  initial  look  at  this  scheme  would  make  it  seem  that  the  hierarchy  has 
again  been  split  in  half,  with  the  domain  names  duplicated.  While  this  duplication  has 
occurred,  and  there  is  now  another  level  added  to  the  hierarchy,  the  actual  number  of 
classes  used  to  store  the  OPERATOR  components  remains  the  same.  The  difference  is 
that  we  can  now  handle  generic  and  specific  source  code  components  with  common 
routines  at  a  much  higher  level  using  inheritance  to  greatly  reduce  the  load  of  the 
database  programmer.  This  class  hierarchy  allows  the  incorporation  of  the  domain 
knowledge  into  the  hierarchy  of  components  that  can  be  described  by  PSDL  and  also 
takes  into  consideration  the  major  classifications  of  program  units  in  the  target 
implementation  language.  Its  final  advantage  over  previously  described  methods 
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Figure  3.5  A  class  hierarchy  for  the  PSDL  OPERATOR  type. 


is  its  adaptability  to  the  object-oriented  classification  model  and  its  ability  to  support 
inheritance  of  both  attributes  and  methods.  This  is  the  recommended  class  hierarchy  for 
the  software  base.  Actual  attributes  and  methods  for  the  objects  contained  in  the  database 
will  be  described  in  more  detail  in  the  next  chapter.  However,  it  can  be  seen  that  for  a 
software  base  of  reusable  Ada  components  the  use  of  PSDL  with  the  addition  of  domain 
dependent  keywords  provides  the  ability  to  classify  components  into  classes  of  a  much 
more  manageable  size  than  currently  exists.  The  hierarchy  must  still  be  accessed  in  some 
manner  in  order  to  be  useful.  This  is  the  subject  of  the  next  section. 
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B.  SEARCHING  THE  OBJECT-ORIENTED  DATABASE 

The  previous  section  describes  a  hierarchical  structure  of  an  object-oriented  database 
with  classes  derived  from  PSDL  and  domain  related  keywords.  To  effectively  use  the 
database  of  components  organized  in  this  type  of  hierarchy,  there  must  be  a  way  to  query 
the  database  that  limits  the  search  to  the  classes  that  will  most  likely  contain  the  needed 
component  This  query  is  formed  from  the  PDSL  specification  by  transforming  the 
specification  using  some  simple  rules.  This  section  describes  the  process  used  in  the 
transformation  and  the  role  of  the  RULE  objects  in  this  process. 

1.  The  Form  of  the  Database  Query 

The  transformation  of  a  PSDL  specification  into  a  form  that  can  be  used  to 
query  the  database  closely  resembles  the  process  used  to  classify  the  components  into 
categories.  The  end  result  of  the  transformation  is  a  tuple  consisting  of  information 
needed  select  the  classes  having  the  best  chance  of  containing  the  component  object  as 
well  as  the  information  needed  to  identify  particular  objects  within  those  classes.  The 
following  information  about  a  component  is  the  minimum  required  to  effectively  query 
the  database.  Other  attributes  can  be  used  to  find  better  matches;  but,  for  purposes  of  this 
discussion,  are  not  included  here: 

Inputs:  The  set  of  input  type  names. 

Outputs:  The  set  of  output  type  names. 

Search_List:  The  set  of  classes  to  be  searched. 
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The  input  and  output  sets  allow  for  the  determination  of  an  approximate  match  of 
individual  components  to  the  PSDL  SPECIFICATION.  The  Search_List  contains  the  list 
of  classes  that,  based  on  analysis  of  the  specification,  have  the  best  chance  of  containing 
the  needed  components.  The  first  two  of  these  attributes  can  be  directly  copied  from  the 
SPECIFICATION.  The  Search_List  is  derived  from  the  transformation  of  the  domain 
related  KEYWORDS  contained  in  the  SPECIFICATION.  This  is  done  using  the  RULE 
class  objects  related  to  each  KEYWORD.  This  process  is  described  in  the  following 
sections. 

2.  The  Structure  of  the  RULE  Objects. 

There  is  a  tradeoff  involved  in  searching  the  database  between  the  time 
involved  in  searching  all  possible  domains,  which  maximizes  the  probability  of  finding 
a  match,  and  the  search  of  a  limited  number  of  domains,  which  may  not  find  an  existing 
component  In  order  to  maximize  the  possibility  of  finding  a  match  for  any  given 
KEYWORD,  rules  are  used.  The  rules  are  based  on  the  possible  domains  that  may  be 
associated  with  a  given  component  object.  These  domains  are  determined  at  the  time  the 
reusable  component  is  added  to  the  database.  A  RULE  object  is  used  to  store  this 
information.  The  RULE  object  also  contains  information  related  to  the  type  of 
OPERATOR  component  within  each  subclass  of  the  domain.  The  general  form  of  a  rule 
attribute  is: 

IF  (  TYPE.MATCH,  OPERATOR.TYPE,  DOMA  IN_N  A  ME)  THEN  (ClassJList) 
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The  TYPE_MATCH  is  the  result  of  matching  the  INPUT  and  OUTPUT  sets  of  type 
names  with  the  available  types  for  the  given  domains  in  the  type  side  of  the  component 
hierarchy.  TYPE_MATCH  identifies  whether  the  component  is  in  the  specific  or  generic 
portions  of  the  hierarchy.  If  TYPE_MATCH  does  not  find  a  match,  then  only  the  generic 
side  of  the  hierarchy  needs  to  be  searched.  The  OPERATOR_TYPE  is  the  result  of 
finding  the  reserved  word  "STATES"  in  the  specification  and  will  identify  the  component 
as  either  a  machine  of  function.  The  DOMAIN_NAME  is  a  KEYWORD  representing  one 
of  the  domains  contained  in  the  hierarchy. 

There  are  rules  for  each  possible  subclass  of  a  given  domain  related  KEYWORD. 
From  the  lattice  structure  presented  earlier  there  are  four  subclasses  for  each  domain 
KEYWORD:  Specific_Machines,  Specific_Functions,  Generic_Machines,  and 

Generic_Functions.  Therefore,  there  are  four  possible  rules  for  deriving  each  domain 
related  Class_List.  The  attributes  representing  these  rules  correspond  to  the  PSDL  and 
Ada  related  forms  of  the  components.  The  Specific_Machine  rule  is  used  when  the  path 
needed  is  to  classes  that  may  contain  *  possible  exact  match  of  a  specific  Ada  package. 
In  this  rule’s  Classjist  are  the  class  names  of  the  Specific_Machine  classes  for  the 
particular  KEYWORD  being  processed  and  any  other  related  domains  determined  during 
component  classification  and  entry  into  the  database.  The  process  of  Class_List  formation 
for  inclusion  in  the  tuple  used  to  query  the  database  is  described  next. 
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3.  The  Transformation  Process 

The  transformation  process  used  here  is  a  pre-processing  step.  It  takes  as  input 
the  PSDL  specification  and  produces  one  or  more  propositions  that  can  be  input  into  a 
rule  base.  The  rule  base  contains  the  list  of  classes  that  most  likely  contain  a  component 
that  matches  all  or  at  least  part  of  the  specification.  In  order  to  form  the  proposition(s) 
the  following  must  be  determined: 

1.  Does  the  SPECIFICATION  contain  TYPEs  that  match  those  already  contained  in 
the  Specific  portions  of  the  database? 

2.  Is  the  component  a  state  machine  (Does  the  SPECIFICATION  contain  the  word 
STATES)? 

3.  Which  domains  have  been  identified  by  the  user  as  most  likely  to  contain  the 
components  (What  are  the  KEYWORDS)? 

The  first  question  is  used  to  determine  if  the  component  is  a  specific  component.  If  the 
types  all  match  those  in  the  specific  side  of  the  TYPE  hierarchy,  then  there  is  possibly 
an  exact  match  for  this  specification  contained  in  one  of  the  specific  classes.  If  there  is 
not  a  specific  type  match  (~TYPE_MATCH)  then  limit  the  search  to  the  generic  classes. 
If  the  SPECIFICATION  contains  the  word  STATES  then  the  component  is  one  of  those 
that  represent  a  state  machine.  Finally,  the  domain(s)  identified  in  the  SPECIFICATION 
represent  the  domains  that  must  be  checked  for  a  possible  match.  The  form  of  the 
proposition  is:  (TYPE_MATCH,  OPERATOR.TYPE,  (DOMAIN_LIST)). 
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However,  the  rules  used  to  match  the  proposition  require  that  each  domain  be 
identified  separately.  So  before  the  rule  base  is  accessed  the  DOMAIN_Ll2»T  is  broken 
into  its  individual  components  and  the  result  is  one  or  more  propositions  of  the  form: 

(TYPE_MATCH,  OPERATOR.TYPE,  KEYWORD) 

There  is  one  proposition  for  each  keyword  contained  in  the  specification.  These 
propositions  are  then  asserted  in  the  rule  base  and  matched  against  existing  rules  to 
determine  Class_lists  for  each  given  domain  given  the  form  of  the  component. 

As  previously  mentioned  the  rules  above  are  stored  in  a  RULE  object  in  the 
database.  The  rule  objects  are  analogous  to  frames.  In  each  domain  or  frame  of 
reference  the  possible  forms  of  components  are  stored  along  with  the  possible  classes  that 
may  contain  matching  components.  Therefore  based  on  the  discussion  of  the  lattice  of 
classification  there  are  four  rules  for  each  domain.  The  forms  are: 

1.  The  Generic  Machine  rule: 

(~TYPE_MATCH,  MACHINE,  KEYWORD)  -> 

(Generic_Machine_Class_List) 

2.  The  Specific  Machine  rule: 

(TYPE_MATCH,  MACHINE,  KEYWORD)  -> 

(Specific_Machine_Class_List) 
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3.  The  Generic  Function  rule: 


(~TY PE_M AT CH ,  FUNCTION,  KEYWORD)  -> 

(Generic_Function_Class_List) 

4.  The  specific  function  rule: 

(TYPE_MATCH,  FUNCTION,  KEYWORD)  -> 

(Specific_Function_Class_List) 

The  Search_List  is  formed  from  the  transformation  of  each  of  the  domain  related 
propositions  using  the  union  of  all  the  Class_Lists.  In  short  the  transformation  process 
can  be  described  by  the  following  steps: 

1.  Convert  the  SPECIFICATION  into  a  basic  proposition  containing  the  results  of 
the  Type_Match  and  Operator_Type  functions  and  the  Domain_List. 

2.  For  each  KEYWORD  form  a  proposition  in  the  form  of  a  rule  antecedent. 

3.  While  there  are  still  propositions  to  process: 

Match  to  Rule„base  to  get  Class_list 
Perform  Union  with  previous  Classjist 

4.  Return  final  Class_List.  This  is  the  Search_List. 

The  final  returned  Classjist  identifies  the  classes  to  search.  It  includes  all  the  classes 
identified  by  the  user  as  well  as  those  identified  in  the  classification  process  of  the 
individual  objects  as  they  were  added  to  the  database  and  included  in  the  rules.  It  is  this 
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list  that  is  used  control  the  search  of  the  object-oriented  database.  An  example  of  this 
process  is  shown  in  the  next  section. 

C.  A  SAMPLE  USE  OF  THE  CLASSIFICATION  SCHEME 

The  previous  sections  have  shown  how  PSDL  could  be  used  as  a  classification 
language  for  storing  reusable  components  in  an  object  oriented  database.  In  this  section 
an  example  is  presented  using  the  component  description  and  implementation  shown  in 
Figures  3.1  and  3.2  and  the  sample  taxonomy  shown  in  Figure  2.1.  Component 
classification,  including  a  description  of  the  associated  RULE  object,  performed  by  the 
database  administrator  at  the  time  the  component  is  loaded,  and  the  derivation  of  the 
Search_List,  required  for  search  and  retrieval  operations,  are  shown  for  the  sample 
specification  and  implementation. 

1.  Classification  of  the  Reusable  Component. 

The  component  shown  in  Figure  3.2  is  an  example  of  a  specific  function  in 
terms  of  PSDL.  The  use  of  the  taxonomy  previously  described  would  place  this  function 
into  one  of  three  domain  related  classes:  Guidance  and  Control,  Asynchronous  Control, 
or  Specific  Equipment  Interface.  The  classification  selected  is  a  function  of  the  database 
administrator  using  input  from  the  domain  analysts.  But,  regardless  of  the  selected 
category,  the  cross-referencing  information  is  built  into  the  associated  RULE  object  for 
the  selected  class.  In  this  case  the  object  is  classified  as  an  instance  of  the  class 
Specific_Function_Guidance_and  Control.  The  Specific  Function  attribute  of  the  RULE 
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object  corresponding  to  Guidance_and_Control  is  updated  to  reflect  the  other  possible 
domains.  The  form  of  the  specific  function  attribute  for  guidance  and  control  is  now: 

(TYPE_MATCHrFUNCTION)(Guidance_and_Control))  -> 
(Guidance_and_Control_Function_SP, 
Asynchronous_Control_Function_SP, 
Specific_Equipment_Interface_Function_SP) 

This  process  is  done  for  each  component  when  added  to  the  database.  For  purposes  of 
illustration  we  assume  that  the  Asynchronous  Control  and  Specific  Equipment  Interface 
rules  have  the  specific  function  attributes  shown  next. 

The  Specific_Function  rule  for  Asynchronous  Control: 

(TYPE_MATCH,FUNCTION,(Asynchronous_Control))  -> 
(Asynchronous_Control_Function_SP, 
General_Purpose_Equipment_Interface_Function_SP, 
Guidance_and_Control_Function_SP, 
Non_Guidance_Control_Function_SP) 


48 


The  Specific_Function  rule  for  Specific_Equipment_Interface: 


(TYPE_MATCHJ7UNCnON)(Specific_Equipment_Interface))  -> 
(Specific_Equipment_Interface_Function_SP, 
General_Purpose_Equipment_Interface_Function_SP, 
Guidance_and_Control_Function_SP, 

Communications_F  unction_S  P , 

Navigation_Function_SP, 

Non_Guidance_Control_Function_SP) 

The  final  part  of  the  classification  process  involves  updating  the  TYPE  side  of  the 
hierarchy  to  include  objects  referencing  the  INPUT  and  OUTPUT  types  used  by  this 
OPERATOR  component.  Once  all  these  operations  have  been  accomplished  the 
component  is  stored.  The  method  of  retrieval  is  described  in  the  next  section. 

2.  Retrieval  of  Components  from  the  Software  Base. 

Retrieval  operations  are  triggered  by  the  CAPS  user  during  the  process  of 
specifying  a  PSDL  operator.  The  input  into  this  process  is  the  PSDL  description 
augmented  with  KEYWORDS.  Figure  3.6  shows  an  augmented  PSDL  specification  for 
the  controller_start_up  OPERATOR  shown  previously. 
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PSDL  DESCRIPTION 

OPERATOR  controller_start_up 

SPECIFICATION 

INPUT  control_panel:  real,  sensor_input:  real 
OUTPUT  missile_control:  real 
MAXIMUM  EXECUTION  TIME  mu 
BY  REQUIREMENTS  controI_panel_max 
KEYWORDS  Guidance_Control,  Specific_Equipment_Interface 
DESCRIPTION 

{  Extracts  the  control  panel  input  and  sensor  input  and 
uses  them  to  calculate  the  control  signal  for  the  missile. 

} 

END 


Figure  3.6  Sample  Augmented  PSDL  Component  Description. 

The  addition  of  the  KEYWORDS  allows  the  component  description  to  be  processed  using 
the  method  described  in  this  chapter.  The  Types  would  be  selected  from  the  domains 
referenced  in  the  component  description  and  used  to  determine  the  TYPE_MATCH  part 
of  the  proposition.  The  examination  of  the  description  shows  no  STATE  variables,  which 
sets  the  second  part  of  the  proposition  to  FUNCTION.  The  domain  list  is  the  list  of 
KEYWORDS  contained  in  the  descripti'  In  this  case  there  are  two  members  contained 
in  the  domain  list.  This  results  in  two  assertions  to  process  and  one  Union  operation  of 
the  class  lists  returned  from  the  rule  base.  The  Search_List  derived  from  processing  this 
component  is: 
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(Guidance_and_Control_Function_S  P, 

Asynchronous_Control_Function_SP, 

Specific_Equipment_Interface_Function_SP, 

General_Purpose_Equipment_Interface_Function_SP, 

Communications_Function_SP, 

N  avi  gation_Func  tion_S  P, 

Non_Guidance_Control_Function_SP) 

This  list  and  the  PSDL  description  are  then  input  into  the  object-oriented  database  to 
continue  the  attempt  to  match  this  specification  with  a  reusable  component.  The  list 
limits  the  classes  to  search  and  the  PSDL  description  provides  the  information  needed  to 
conduct  the  more  detailed  operations  required  for  selection  of  components  from  the 
database  and  incorporation  of  the  component  into  the  prototype. The  inclusion  of  the  rules 
derived  from  the  classification  process  insures  that  a  more  complete  search  will  be  done 
and  solves  many  of  the  problems  associated  with  cross  referencing.  A  system  that 
implements  this  process  is  the  goal  of  the  design  effort.  A  structure  that  supports  this 
effort  is  described  in  the  next  chapter. 
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IV.  CONCEPTUAL  DESIGN  OF  THE  SOFTWARE  BASE 


In  this  section  an  extended  conceptual  design  of  the  software  base  is  presented.  The 
goal  is  to  integrate  the  concepts  presented  earlier  in  the  discussion  of  domain  analysis, 
rule  based  systems,  and  object  oriented  programming  and  databases,  into  the  design  of 
a  subsystem  that  extends  the  current  approach  used  in  CAPS.  The  objective  of  the  design 
presented  here  is  to  identify  the  major  objects  that  are  required  to  implement  this 
subsystem.  Additionally,  for  the  object-oriented  database  component,  the  classes  of  objects 
and  the  methods  required  of  these  classes  to  support  the  ultimate  goal  of  integration  of 
reusable  components  into  a  CAPS  prototype  as  well  as  the  basic  functions  required  for 
building  and  maintaining  this  database,  are  described. 

The  design  presented  here  is  generic  in  nature.  It  describes  a  database  that 
represents  domains  by  defining  small  classes  of  reusable  component  objects  using 
concepts  from  the  domain  analysis  and  the  PSDL  language  and  organizing  them  into  a 
hierarchy.  It  also  stores  rules  for  each  domain  in  a  specialized  object  class.  The  search 
of  this  database  is  aided  by  the  transformation  of  the  specification  prior  to  querying  the 
database  as  described  in  Chapter  III.  The  results  of  the  transformation  and  application  of 
rules  is  the  identification  of  the  classes  to  search  in  the  database. 
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The  discussion  begins  with  the  description  of  the  reusable  software  base  and  its 
interface  to  the  CAPS  system.  This  is  followed  by  an  explanation  of  the  major 
subsystems  required  to  integrate  reuse  into  the  system.  This  description  will  be  presented 
following  the  object-oriented  analysis  methodology  described  in  Chapter  n.  Finally  the 
major  forms  of  the  objects  used  to  store  reusable  components  and  the  specialized  class 
used  to  store  the  rules  is  presented.  The  attributes  and  methods  that  each  of  the  major 
object  classes  need  to  support  the  required  system  functions  is  described  in  sections 
detailing  each  major  object  class. 

A.  THE  REUSABLE  SOFTWARE  BASE  SYSTEM  ARCHITECTURE 

Chapter  II  presents  an  overview  of  the  CAPS  architecture.  The  Software  Base 
Management  System  component  contains  two  supporting  databases:  a  database  of 
reusable  software  components  and  a  design  database.  The  component  we  are  concerned 
with  here  is  the  reusable  software  base.  For  purposes  of  this  discussion  the  design 
database  can  be  considered  another  part  of  the  CAPS  environment  described  in  Figure  4. 1 . 
This  is  reasonable  because  its  interface  with  the  software  base  of  reusable  components  is 
the  same  as  that  of  the  other  components  of  CAPS.  Other  parts  of  the  environment  that 
interface  with  the  reusable  software  component  subsystem  are  the  syntax  directed  editor 
and  the  translator.  In  all  cases  the  basis  of  the  interface  is  a  PSDL  specification. 
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Figure  4.1  The  Software  Base  System  Architecture 

The  major  parts  of  the  software  base  of  reusable  components  subsystem  are  the  pre¬ 
processor,  object-oriented  database  and  the  decision  support  modules.  These  are 
described  in  the  following  sections. 

1.  The  Preprocessor 

The  preprocessor  consists  of  those  parts  needed  to  determine  the  SearchJJst 
of  classes  likely  to  contain  reusable  components.  Included  in  this  module  are  a  parser 
that  does  the  transformation  of  the  PSDL  specification  into  a  proposition  and  the  rule 
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base.  The  rule  base  is  formed  by  retrieving  selected  rule  objects  from  the  rule  class  in 
the  object-oriented  database.  Specific  rule  objects  are  determined  by  the  Domain_List 
formed  during  the  transformation  of  the  specification.  Associated  methods  contained  in 
the  rule  class  are  covered  in  the  description  of  the  rule  class  later  in  this  chapter. 

2.  The  Decision  Support  Module 

This  module  performs  the  functions  of  object  selection  and  incorporation  of 
the  reusable  software  component  into  the  prototype.  There  are  a  number  of  alternatives 
that  can  be  considered  in  the  implementation  of  this  module.  These  include  the 
implementation  of  a  manual  means  of  browsing  components  identified  during  the  iteration 
through  the  classes,  the  selection  through  automated  analysis  of  other  pans  of  the 
specification  or,  more  likely,  a  combination  of  the  two.  Research  in  this  area  is  currently 
underway.  The  proposed  structure  is  designed  to  support  this  research. 

3.  The  Object-Oriented  Database 

This  module  contains  the  actual  components  with  the  attributes  and  methods 
needed  to  support  addition,  deletion,  modification,  and  update  of  rules  used  to  support  the 
search  and  selection  of  components.  Note  that  methods  must  exist  that  allow  the  database 
to  interact  with  both  of  the  other  modules.  The  structure  of  the  database  and  the 
attributes  and  methods  are  described  in  the  next  section. 
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B.  THE  STRUCTURE  OF  THE  OBJECT-ORIENTED  DATABASE 


There  are  three  main  types  of  objects  that  are  needed  to  implement  reuse  in  the 
CAPS  software  base  of  reusable  components.  Two  are  already  supported  to  a  limited 
extent  -  TYPES  and  OPERATORS.  These  classes  of  components  represent  the  major 
constructs  used  in  PSDL.  However,  the  previous  design  [Ref.  6]  is  oriented  to  storing 
and  retrieving  components  which  are  already  well  known  by  the  user.  To  properly  use 
the  software  base,  the  user  must  know  the  exact  name  of  the  component  to  retrieve  it. 
The  approach  taken  in  this  design  is  to  create  a  class  hierarchy  to  support  a  search  based 
on  partial  description  of  the  object  as  described  in  Chapter  III.  To  do  this  the  TYPE  side 
of  the  class  hierarchy  is  expanded  to  include  subclasses  associated  with  the  application 
domains  that  they  are  used  in.  The  OPERATOR  class  is  expanded  in  a  similar  manner 
incorporating  domain  related  classification  into  the  expanded  hierarchy  well  as 
information  on  the  form  of  the  component  from  the  target  implementation  language.  To 
support  search  operations  an  additional  object  class,  containing  RULE  objects,  is  added. 
The  RULE  class  contains  the  simple  rules  used  to  support  search  and  retrieval  operations. 
A  top-level  description  of  the  extended  database  hierarchy  is  shown  in  Figure  4.2.  All 
classes  in  an  object-oriented  database  are  defined  as  subclasses  of  some  basic  object  class 
that  provides  the  basic  attributes  and  methods  needed  to  provide  basic  database  operations 
such  as  add,  delete,  modify  etc.  These  attributes  and  methods  are  inherited  and  may  be 
modified  further  down  the  class  hierarchy.  We  assume  that  this  is  the  case  in  this  design 


56 


is  the  case  in  this  design  and  use  the  class  labeled  OBJECT  as  the  base  class.  The 
following  sections  further  elaborate  the  top-level  classes  attached  to  the  base  class  and 
describe  the  required  attributes  and  methods  of  these  types  of  objects.  Many  of  these 
attributes  and  methods  are  inherited  from  higher  levels,  but  modified  to  provide  additional 
capability. 
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1.  The  TYPE  Objects 

The  TYPE  hierarchy,  or  subtree  of  the  component  hierarchy,  is  composed  of 
objects  that  support  the  Ada  type  definitions  used  in  the  component  objects  found  in  the 
OPERATOR  portion  of  the  database.  From  the  domain  analysis  and  commonality  studies, 
types  used  in  the  implementation  of  OPERATORS  and  associated  with  the  application 
domains  in  the  software  base  are  identified.  It  is  this  association  that  is  used  to  form  the 
hierarchy  of  types.  An  example  of  such  a  hierarchy  is  shown  in  Figure  4.3. 
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Each  of  the  actual  objects  is  basically  the  same.  The  classification  scheme  is 
merely  a  means  of  organizing  the  objects  into  a  hierarchy  based  on  the  application 
domains.  There  are  two  advantages  to  this  separation.  First,  the  operations  and  the 
attributes  needed  by  all  TYPEs  can  be  described  once  at  a  higher  level  and  inherited  by 
each  of  the  domain  dependent  subclasses.  The  operations  needed  to  support  retrieval  can 
also  be  stored  at  a  higher  level  and  invoked  by  sending  the  message  to  the  object  class 
at  the  domain  level.  The  operation  is  inherited  and  applied  to  the  referenced  class. 
Second,  capabilities  to  provide  indexing  information  are  often  provided  for  classes  defined 
in  an  object-oriented  database  at  the  class  level.  The  subdivision  of  TYPE  into  the 
smaller  domain  related  classes  allows  us  to  take  advantage  of  this  capability  in  the  actual 
implementation. 

The  following  are  the  required  attributes  and  methods  for  the  TYPE  side  of  the 
hierarchy  in  the  Software  Base: 

Attributes: 

Name:  A  string  representing  the  Ada  Type  Name.  Inherited  from  the  Component 
Class  definition. 

OperatorJList:  The  set  of  associated  OPERATORS  in  the  same  domain  using  this 
type.  Supports  Add  and  Delete  Operations  in  the  OPERATOR  hierarchy.  Can  also 
be  used  to  trigger  delete  operations  for  individual  instances  of  TYPE  objects. 

Ada_Text:  The  actual  text  of  the  type  declaration  in  Ada  Syntax.  Definition 
inherited  from  the  Component  class. 
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Description:  Information  which  describes  the  type  and  may  be  useful  while 
browsing  the  database. 

PSDL  Specification:  The  PSDL  specification  for  the  TYPE.  PSDL  Descriptions 
are  required  for  more  detailed  analysis. 


Methods: 

Add_Type:  Supports  the  addition  of  components  to  the  software  base  by  updating 
the  types  contained  in  the  domain  of  the  added  component.  Used  in  conjunction 
with  Add_Operator  method  in  the  OPERATOR  side  of  the  hierarchy.  Types  are 
only  added  when  required  to  support  OPERATORS. 

Delete_Type:  Supports  deletion  of  types,  as  required,  from  the  software  base. 
Deletion  is  done  when  all  OPERATORS  contained  in  the  Operator_List  have  been 
eliminated.  Done  in  conjunction  with,  and  triggered  by  the  deletion  of  OPERATOR 
components. 

Get_type:  Used  to  get  the  Ada  text  representation  of  the  type.  May  be  used  in 
display  operations  or  operations  to  incorporate  class  into  program.  Displays  the 
Ada_Text  and  description  to  the  screen. 

Form_type_list:  Used  to  reference  the  class  hierarchy  for  class  names  contained  in 
the  Domainjist  formed  as  part  of  the  transformation  process  of  the  PSDL 
specification.  Returns  the  objects  found  in  each  of  the  classes.  Used  in 
transformation  process  of  PSDL  SPECIFICATION  to  proposition.  Supports  the 
TYPE_MATCH  operation  described  earlier. 


This  description  includes  the  minimum  required  set  of  operations  and  attributes. 
This  section  of  the  hierarchy  has  a  great  deal  of  future  potential.  For  example,  an  area 
which  may  benefit  from  the  reuse  of  class  information  is  the  definition  of  data  streams 
in  the  graphical  editor.  However,  since  the  main  problem  addressed  in  this  thesis  is 
retrieval  of  the  OPERATOR  type  objects,  the  discussion  of  the  TYPE  hierarchy  and 
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objects  is  limited  to  the  attributes  and  methods  needed  to  support  the  maintenance  of  the 
database  and  retrieval  of  OPERATORS. 

2.  The  OPERATOR  Objects. 

The  OPERATOR  objects  represent  and  encapsulate  the  major  reusable 
components  contained  in  the  software  base.  It  is  here  that  the  actual  code  of  Ada 
procedures,  functions,  and  packages  is  stored.  Galik  provides  a  good  description  of  the 
major  portions  of  the  OPERATOR  class  used  for  each  of  the  objects  [Ref.  6].  However, 
since  he  provides  only  one  OPERATOR  class,  he  does  not  address  one  of  the  strengths 
of  object-oriented  databases.  This  is  the  ability  to  successively  specialize  objects  in  a 
hierarchical  fashion.  Figure  4.4  shows  an  example  of  this  expanded  hierarchy.  The 
specialization  of  object  classes  by  functional  areas  defined  during  domain  analysis, 
combined  with  the  major  forms  of  OPERATORS  that  can  be  represented  in  PSDL  results 
in  an  expanded  hierarchy  that  can  be  searched  more  efficiently. 

The  requirements  of  the  prototyping  system  make  it  necessary  to  store  more  than 
just  source  code  in  the  component  objects.  Attributes  such  as  timing  characteristics  and 
other  descriptive  information  must  be  put  into  separate  portions  of  the  object  to  assist  in 
the  evaluation  and  selection  process.  There  is  also  a  need  to  store  information  needed  to 
cross  reference  objects  and  classes.  This  is  done  for  two  reasons.  The  first  is  to  insure 
a  complete  search  is  conducted  during  retrieval  operations.  The  second  is  to  insure  that 
all  components  needed  to  properly  use  the  referenced  component  are  also  found.  Two 
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Figure  4.4  The  OPERATOR  hierarchy. 


attributes  are  defined  to  provide  the  additional  information  needed  to  support  these 
operations.  The  first  of  these  is  a  "Withing"  list  which  is  used  to  locate  support  modules 
needed  by  the  component  to  be  properly  used  in  a  program.  This  directly  corresponds 
to  the  With  of  the  Ada  language.  The  other  main  reference  attribute  is  a  set  of  related 
classes.  This  is  required  because  of  the  possibility  of  overlap  between  the  functional 
domains.  Any  given  component  will  be  classified  into  one  domain  related  class. 
However  some  may  have  applicability  to  more  than  one  class.  A  master  path  list 
containing  the  names  of  all  domains  related  to  the  members  of  each  class  is  maintained 


62 


in  the  RULE  object  section  of  the  database.  The  attributes  and  methods  needed  for  all 
objects  at  the  base  level  of  the  OPERATOR  section  of  the  hierarchy  are: 


Attributes: 

Name:  The  name  of  the  component.  This  name  is  the  same  as  that  of  the  Ada 
component  stored  in  the  text  portion  of  the  object. 

Inputs:  The  set  of  variable  and  type  names  used  in  the  implementation  of  the 
object 

Outputs:  The  set  of  variable  and  type  names  used  in  the  implementation  of  the 
object 

With:  The  set  of  objects  used  to  fully  implement  the  operations  of  the  component 
object  using  the  Ada  "With"  capability. 

Path_list:  The  set  of  related  classes  that  may  also  contain  modules  with  the  same 
or  related  functionality  as  the  referenced  component. 

Requirements_list:  Used  to  describe  the  functionality  of  the  component.  In  PSDL 
terminology  the  "BY  REQUIREMENT"  phrases  would  be  stored  in  this  construct. 
This  attribute  is  not  required  for  the  search  or  retrieval  process  described  here.  May 
be  useful  in  the  Decision  Support  module  for  more  detailed  analysis  of  the 
individual  component  objects. 

Description:  Text  describing  the  module.  In  the  form  of  the  PSDL 

SPECIFICATION  with  documentation  added  as  natural  language  text. 

Source:  The  Ada  code  of  the  specification  and  body  of  the  component. 

Timing:  Maximum  Execution  Time.  The  timing  characteristics  may  also  be  detailed 
as  separate  attributes. 


63 


Methods: 


Get_the_Object:  Needed  to  support  further  processing  or  display  of  the  object  for 
review  by  the  user. 

Display _Description:  Displays  the  Description  text  only  for  evaluation  by  the  user. 

Add_Operator:  Used  by  the  software  base  administrator  or  librarian  to  add 
components  of  type  OPERATOR  to  the  database  and  update  associated  TYPE  and 
RULE  objects.  Refines  the  basic  add  operation  defined  at  higher  levels  in  the 
hierarchy. 

Modify_Operator:  Needed  to  change  information  (attributes)  of  the  individual 
objects.  Used  by  the  system  administrator  or  librarian.  Refines  modify  operations 
inherited. 

Delete_Component:  Used  to  delete  components  no  longer  needed  and  update 
associated  TYPE  and  RULE  objects.  Also  a  function  of  the  database  administrator 
or  librarian.  Updates  the  Operator_List  on  the  TYPE  side  of  the  hierarchy  and  may 
cause  the  method  to  delete  a  TYPE  to  be  activated.  Refines  inherited  methods  to 
delete  objects. 

Write_Component:  Refines  inherited  write  methods  inherited  from  the  Component 
class.  Used  to  add  selected  objects  to  the  prototype  in  progress.  As  CAPS  is 
currently  implemented  this  method  would  open  and  write  to  the  file  the  source  code 
for  the  selected  object.  This  method  would  vary  depending  on  the  location  of  the 
selected  object  in  the  hierarchy.  There  are  two  main  options: 

Specific  OPERATORS:  This  method  will  copy  the  text  of  the  source 
attributes. 

Generic  OPERATORS:  The  instantiation  will  be  done  using  the 

Write_Component  method  found  in  the  generic  side  of  the  OPERATOR  class 
hierarchy.  This  is  an  example  of  overloading  of  method  names  allowed  in 
object-oriented  languages  as  explained  in  Chapter  n. 

Get_Axiom:  This  method  is  used  for  support  of  more  detailed  matching  operations 
currently  being  researched.  The  AXIOM  is  a  CAPS  construct  used  to  more  fully 
describe  in  formal  terms  the  OPERATORS. 
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The  attributes  and  methods  presented  here  are  considered  the  minimum  required  to 
support  the  process  of  matching  PSDL  specifications  to  reusable  software  components 
described  in  this  thesis.  There  arc  many  other  requirements  that  must  be  met  as  pan  of 
the  software  development  process.  Some  of  these  include  version  control,  for  the  objects 
contained  in  the  database,  and  documentation  requirements  supporting  the  requirements 
definition  and  design  processes  CAPS  is  designed  to  support.  These  are  just  two  of  the 
areas  that  may  be  expanded  in  future  research. 

3.  The  RULE  Objects. 

Objects  contained  in  this  class  are  used  to  assist  in  the  selection  of  classes  in 
the  OPERATOR  portion  of  the  database  to  search  based  on  the  query  formed  by 
transformation  of  the  PSDL  specification.  The  goal  of  the  rule  base  is  identify  the  "most 
likely"  class(es)  to  search  in  the  database.  The  RULE  class  contains  simple  first  order 
logic  representations  of  the  Search_Lists  (or  maybe  more  appropriately  class  lists)  that 
match  the  pattern  of  the  input  proposition  formed  by  transforming  the  PSDL  specification 
into  a  proposition  that  can  be  used  by  the  rule  base.  The  end  result  of  the  processing 
done  by  the  rule  base,  as  described  in  Chapter  III,  is  a  master  search  list  of  potential 
cl.  es  which  may  contain  the  required  objects.  This  list  used  to  guide  the  subsequent 
search  of  the  database. 

The  rules  themselves  are  built  by  using  the  basic  features  expected  from  any  PSDL 
component  on  the  left  hand  side  of  the  rule  (the  antecedent)  and  the  related  class  lists 
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found  in  the  objects  of  each  domain’s  specific  and  generic  classes  on  the  right  hand  side. 
As  new  objects  are  added  to  each  class,  the  related  class  list  is  compared  to  that  already 
existing  for  the  class.  If  some  new  element  is  found  in  the  class  list  it  is  added  to  that 
portion  of  the  corresponding  rule  object’s  list. 

The  description  of  the  class  RULE  objects  follows: 


Attributes: 

Name:  The  domain  name  of  the  domain  being  represented  by  the  rules  stored  in 
this  object. 

Gen_Machine_Path:  Rule  representing  the  path  (class  list)  to  be  searched  if  the 
antecedent  results  in  limiting  the  search  of  related  classes  to  only  generic  classes. 
The  generic  machine  rule. 

Gen_Function_Path:  Rule  representing  the  path  (class  list)  to  be  searched  if  the 
antecedent  results  in  limiting  the  search  of  related  classes  to  only  generic  classes 
that  do  not  contain  machines.  The  generic  function  rule. 

Specific_Machine_Path:  The  comprehensive  search  path  for  the  named  starting 
domain.  This  path  list  contains  all  of  the  classes  including  generic  and  specific  for 
the  named  domain  of  interest.  The  specific  rule  for  finding  machine  components. 

Specific_Function_Path:  The  comprehensive  search  path  for  the  function 

components.  This  path  list  contains  all  of  the  classes  including  generic  and  specific 
for  the  function  components.  The  specific  rule  for  finding  function  components. 


Methods: 

Get_Rules  (Domain_list):  Method  to  build  the  rule  base  from  the  identified  domain 
lists.  Called  by  the  Preprocessor  module.  Rules  returned  are  used  to  get  the  class 
list  that  is  searched. 
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Add_Rule:  Method  to  create  instances  of  the  class  rule  when  creating  new  domains 
of  objects  in  the  database.  Inherited  from  the  OBJECT  class  and  triggered  by  the 
creation  of  a  new  class  by  the  database  administrator  or  librarian.  Initially  it  would 
be  empty.  As  objects  were  added  it  would  be  updated  using  the  modify  rule 
method  below. 

Modify  _Rule:  (Domainjist):  For  an  existing  instance  this  method  takes  a  modified 
list  of  domains  and  modifies  the  Gen_Path  and  Specific_Path  attributes  to  reflect 
changes  in  the  Path_list  of  the  domain  related  class  (found  in  the  OPERATOR 
hierarchy).  This  method  would  be  used  by  each  OPERATOR  create  process. 
Performs  a  comparison  of  the  new  domain  list  included  with  the  newly  created  or 
modified  object  and  would  perform  an  "OR"  or  Union  type  operation  on  the  lists 
to  insure  any  new  classes  were  added  to  the  path  lists. 

Delete_Rule:  When  an  entire  domain  related  group  of  classes  are  no  longer 
required  the  rule  object  related  to  this  domain  would  have  to  be  deleted.  This 
method  would  be  inherited  from  the  basic  OBJECT  class  and  triggered  by 
maintenance  programs  used  by  the  database  administrators. 


The  processing  of  the  rules  is  part  of  the  preprocessing  done  prior  to  the  actual 
search  of  the  OPERATOR  portion  of  the  database.  It  is,  therefore,  important  to  decide 
at  what  point  in  the  prototyping  session  the  rule  base  gets  built.  The  major  question  to 
be  answered  is  whether  or  not  to  build  a  comprehensive  rule  base  at  the  beginning  of 
each  session,  limit  the  operator  of  the  CAPS  to  some  subset  of  domains  per  session,  build 
a  new  rule  base  for  every  query,  or  start  with  a  rule  base  formed  from  a  given  set  of 
domains  and  continue  to  add  rules  as  more  domains  become  active  during  the  session. 
The  approach  in  defining  the  attributes  and  methods  used  in  the  RULE  class  definition 
is  to  remain  flexible  enough  to  support  any  of  these  approaches. 
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C.  SUPPORT  OBJECT  CLASSES  AND  COMPOSITION  OF  OBJECTS 


One  of  the  more  important  capabilities  of  the  object-oriented  development  model 
and  object-oriented  databases  in  particular  has  not  yet  been  considered.  When  designing 
the  detailed  implementation  it  will  be  necessary  to  provide  the  user  capabilities  to  display 
the  object  or  perform  manipulation  on  various  attributes.  Rather  than  define  methods  for 
manipulation  of  each  part  of  an  object,  we  can  take  advantage  of  system  supplied  object 
classes  that  can  be  composed  into  parts  of  the  specialized  objects  we  are  interested  in. 
In  Object-oriented  databases  there  is  often  an  environment  already  available  built  on  to 
the  basic  Object  definition  and  inherited  by,  or  in  some  way  made  accessible  to  all 
subclasses  of  object.  This  is  the  case  in  the  Ontos  system  [Ref.  19],  the  projected 
implementation  system  for  the  expanded  software  base  described  in  this  thesis.  The  next 
chapter  describes  some  of  the  more  useful  capabilities  this  system  may  provide  in  support 
of  the  construction  of  the  expanded  Software  Base  Management  System. 
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V.  IMPLEMENTATION  ISSUES 


The  previous  chapter  describes  the  needed  objects  and  organization  of  the  class 
hierarchy  to  support  selection  of  reusable  software  components  using  simple  rules  to 
determine  where  to  start  the  search.  The  major  goal  addressed  in  the  description  of  the 
objects  was  to  identify  the  structures  needed  to  support  the  search  process.  The  overall 
goal  of  the  pre-processor  and  database  components  of  the  system  described  here  is  to 
narrow  the  number  of  candidate  objects  and  present  a  best  qualified  set  of  candidates  to 
the  decision  support  component  of  the  system  for  more  detailed  analysis.  To  insure  a 
more  complete  search  of  the  database,  cross-referencing  information  needed  to  support 
this  search  is  stored  as  one  attribute  of  the  major  types  of  reusable  component  objects. 
Additional  attributes  needed  to  support  user  interface,  documentation,  and  more  detailed 
matching  operations  are  not  included  in  this  description.  Supporting  object  classes 
included  in  the  implementation  environment  are  a  means  of  further  abstracting  portions 
of  the  custom  object.  The  design  presented  is  based  on  exploiting  the  object-oriented 
model  and  the  concepts  of  domain  analysis  for  a  generic  domain.  Chapter  IV  avoids 
specific  issues  related  to  the  actual  building  of  this  system.  In  this  chapter  some  of  these 
issues  are  addressed. 
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A.  THE  ONTOS  OBJECT-ORIENTED  DATABASE  SYSTEM 


Ontos  is  the  system  currently  projected  for  the  implementation  of  the  Software  Base 
Management  Component  of  CAPS  [Ref.  19].  It  is  the  second  effort  from  the  developers 
of  the  VBase  OODBMS  system  currently  used  in  CAPS  [Ref.  6].  There  are  several  major 
improvements  that  are  included  in  this  product.  It  is  designed  to  provide  direct  object 
access  from  C++  applications  and  to  provide  much  better  performance  than  VBase.  Plans 
are  to  improve  the  overall  environment  to  ultimately  provide  a  graphical  oriented 
environment  to  support  graphical  schema  definition  and  modification,  menu,  form  and 
report  generation,  query  by  example,  database  browser,  and  simple  applications  generation 
[Ref.  19:  p.  5].  It  is  one  of  the  first  commercially  available  object  databases  supporting 
the  C++  programming  language. 

The  classes  provided  by  Ontos  contain  many  of  the  support  objects  previously 
mentioned  as  important  to  the  implementation  of  the  expanded  software  base  system.  The 
built-in  data  types  provided  by  the  interface  language.  Aggregate  Classes  used  to  collect 
groups  of  objects,  and  an  Iterator  Class  which  can  be  used  to  step  through  the  attributes 
of  individual  objects  or  Aggregates  of  objects  are  probably  the  most  important.  These 
and  other  support  classes  and  functions  are  contained  in  the  Client  Library  provided  by 
Ontos.  [Ref.  19:  pp.  51-96] 

The  base  classes  of  the  Ontos  system  are  the  CleanupObj,  Entity,  and  Object. 
CleanupObj  provides  the  Iterator  capabilities  useful  in  stepping  through  the  attributes  of 
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individual  objects  or  objects  collected  in  aggregates.  Entity  provides  uniform  reference 
semantics  for  classes  and  C++  primitives.  Primitives  represent  the  C++  built-in  types. 
Object  provides  persistent  object  definition  for  objects  stored  in  the  database.  The  schema 
definition,  directory  capabilities,  and  Aggregate  classes  mentioned  previously  as  important 
to  the  implementation  of  the  search  and  retrieval  methods  described  in  this  thesis  are  also 
derived  from  this  class.  Classes  for  defining  the  operations  and  attributes  to  be  included 
in  objects  of  the  customized  classes  are  included  here  as  well.  The  Object  class  provides 
operations  that  can  be  used  in  the  definition  of  more  complex  methods  at  different  levels 
in  the  hierarchy.  For  example,  modification  of  the  New-Instance  constructor  function  for 
the  OPERATOR  class  described  in  the  previous  section  to  allow  the  update  of  the  RULE 
class  object  associated  with  this  class  could  be  done  at  the  OPERATOR  level  and 
inherited  to  each  of  the  subclasses.  [Ref.  19:  pp.  50-96] 

In  summary  the  Ontos  object  database  has  adequate  capability  to  quickly  implement 
the  database  needed  to  support  the  reuse  system  described  in  this  thesis.  It  also  has  the 
capability,  using  the  Set  class  and  Iterators,  to  support  operations  that  further  narrow  the 
number  of  possible  objects  selected  as  candidates  for  detailed  matching  operations 
performed  by  the  decision  support  module  described  earlier.  This  would  further  aid  the 
decision  process  this  system  is  designed  to  support.  Implementation  of  a  system  using 
Ontos  is  required  to  test  many  of  these  features. 
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B.  PROTOTYPING  OF  THE  EXPERT  SYSTEM  COMPONENTS 

Two  of  the  three  components  described  in  the  architecture  of  the  expanded  software 
base  management  system  are  based  on  expert  systems.  The  Ontos  system  described 
previously  provides  the  capability  for  providing  the  needed  information  to  support  both 
the  pre-processing  and  decision  support  components  of  the  software  base  management 
system  described  here.  The  C  and  C++  programming  languages  are  useful  for  building 
higher  performance  expert  systems  than  those  written  in  Lisp  and  Prolog.  However  this 
conversion  is  normally  done  only  after  the  concepts  are  proven  and  performance  becomes 
the  primary  consideration.  There  is  a  general  method  used  in  expert  systems 
development.  In  the  systems  surveyed  as  part  of  this  thesis  the  expert  systems 
components  were  all  developed  as  follows:  [Refs.  1,3,19-21]: 

1.  Problem  Assessment  (Domain  Analysis) 

2.  Prototyping  and  Knowledge  Base  Construction 

3.  Software  Engineering  and  Program  conversion 

The  expert  system  components  were  not  converted  until  the  knowledge  and  rules  needed 
for  the  problem  domain  were  reasonably  firm.  It  is  then  that  performance  becomes  the 
major  issue.  The  methodology  presented  in  this  thesis  and  the  process  of  domain 
language  development  for  use  in  CAPS  would  benefit  greatly  from  the  construction  of  a 
prototype  expert  system  which  could  be  continually  improved.  New  rules  and  expanded 
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frames  of  reference  could  still  be  incorporated  into  the  RULE  objects  in  the  OODBMS 
and  used  by  a  system  based  on  the  interface  language  of  the  database. 

C.  THE  REUSABLE  SOFTWARE  COMPONENTS 

As  previously  noted  the  reusable  components  in  a  given  system  may  have  many 
different  definitions.  In  CAPS  the  system  is  relatively  flexible,  allowing  systems  to  be 
specified  at  various  levels  of  abstraction.  Subsystems  representing  high  level  systems  and 
many  lines  of  code  can  be  stored  in  the  same  database  providing  low-level  functions. 
This  makes  it  possible  to  reuse  code  written  at  varying  levels  of  abstraction  and  from  a 
variety  of  sources. 

The  CAMP  project  also  took  an  approach  similar  to  that  used  in  CAPS  for 
development  of  a  set  of  parts  (reusable  components)  [Refs.  22-25]  to  support  the  missile 
embedded  systems  environment.  Many  of  the  modules  in  CAMP  represent  embedded 
system  functions  that  are  applicable  across  a  wide  range  of  embedded  systems 
applications.  Not  all  of  CAMP  can  be  used,  and  because  of  the  composition  strategy  used 
in  CAMP  there  are  several  components  that  may  require  restructuring  to  be  used  in 
CAPS.  This  is,  however,  the  best  source  of  real  components  for  embedded  systems  use 
that  was  found  during  this  research.  Another  source  which  has  many  components  which 
may  prove  useful  is  the  Ada  Software  Repository  [Ref  26].  Many  mathematical  and  data 
structure  parts  can  be  found  in  this  system.  However,  the  organization  of  this  system 
does  not  make  it  easy  to  find  any  particular  component. 
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D.  DEVELOPMENT  STRATEGY 

The  preceding  sections  have  mentioned  many  of  the  areas  that  must  be  considered 
in  the  development  of  the  proposed  system.  The  normal  development  of  a  domain  related 
programming  library  or  reusable  component  database  relies  on  the  development  of  domain 
dependent  systems  that  cannot  be  easily  expanded  or  reconfigured  to  add  new  classes  to 
the  system.  The  development  of  flexible  database  support  for  a  specific  application 
domain  is  based  on  having  the  ability  to  add,  delete  or  reorganize  entire  classes  in  the 
database.  The  system  described  here  allows  a  modular  development  strategy.  It  is 
possible  to  reconfigure  the  domain  language  by  identifying  the  domain  related 
KEYWORDS  from  those  already  in  the  database  adding  those  needed  to  describe  new 
classes  of  components.  This  development  strategy  allows  the  development  of  new 
application  specific  rule  bases  using  already  existing  classes  and  reuse  of  existing  RULES. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  CAPS  environment  is  a  collection  of  tools  which  allow  the  development  of 
systems  using  a  methodology  based  on  iterative  decomposition  and  refinement  of 
programs  supporting  hard  real-time  requirements.  The  CAPS  system  uses  the  Prototyping 
System  Description  Language  (PSDL)  to  support  this  development  process.  Descriptions 
of  subsystems  or  program  modules  written  in  PSDL  may  be  further  decomposed, 
translated  or  incorporated  into  the  prototype  in  the  form  of  a  reusable  software 
component  The  subsystem  used  to  manage  reuse  in  CAPS  is  the  software  base 
management  system.  This  subsystem  does  the  identifies  and  supports  incorporation  of 
reusable  software  components  into  the  prototype.  This  is  done  through  analysis  of  the 
PSDL  description,  search  of  the  database  of  reusable  components  for  potential  matches, 
and  detailed  matching  operations  to  determine  if  an  acceptable  component  exists. 

The  previous  organization  of  the  software  base  of  reusable  components  is  not 
adequate  to  perform  its  intended  function  effectively  or  efficiently.  In  this  thesis  a 
revised  and  expanded  structure  for  the  software  base  was  presented  that  takes  advantage 
of  the  object-oriented  model  and  characteristics  of  object-oriented  databases  to  allow  the 
classification  of  reusable  components  into  classes  which  are  more  representative  of  the 
given  application  domain.  As  part  of  this  process  PSDL  was  evaluated  for  its 


effectiveness  as  a  classification  language.  PSDL  in  its  basic  form  is  adequate  for  the 
classification  of  OPERATORS  and  TYPES  into  the  basic  form?  used  during  prototyping 
sessions.  PSDL  augmented  with  a  few  domain  oriented  keywords  which  are  allowed  in 
the  language  definition  further  improves  the  ability  of  the  developers  to  incorporate 
domain  knowledge  into  the  reuse  system.  Using  PSDL  augmented  by  keywords  allows 
the  developers  of  prototyping  systems  supporting  particular  areas  to  build  reusable 
component  databases  which  represent  the  major  objects  or  subsystems  and  functions  for 
identified  domains  of  interest 

The  use  of  rules  to  support  retrieval  of  components  from  the  database  was  also 
explored.  Again,  the  focus  was  on  evaluation  of  rules  which  could  be  described  using 
parts  of  the  specification  portion  of  a  PSDL  description.  The  goal  of  the  rule  base  is  to 
identify  the  most  likely  class  or  classes  to  search  for  components.  The  rules  are  stored 
in  specialized  objects  in  the  database  and  provide  cross  referencing  information  needed 
to  insure  a  more  complete  search  of  the  database  for  the  desired  component.  The  PSDL 
description  is  transformed  into  one  or  more  propositions  that  can  be  asserted  in  the  rule 
base  to  get  a  list  of  the  classes  most  likely  to  contain  the  component.  This  list  along  with 
the  description  form  the  input  to  the  object-oriented  database  and  provide  needed 
information  to  perform  more  detailed  matching  operations  needed  to  select  components 
fur  incorporation  into  the  prototype. 
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During  the  course  of  this  research  several  areas  of  commonality  became  apparent 
in  research  efforts  aimed  at  reuse  of  software.  All  were  using  some  sort  of  rule  base  to 
determine  the  transformation  or  composition  strategies  to  be  used.  All  were  oriented 
toward  the  transformation  of  some  higher  order  language  into  a  form  that  could  be  used 
to  either  find  components  stored  in  a  database  or  generate  components  in  a  target 
language.  All  approaches  used  some  form  of  pattern  matching  to  rate  and  select 
components.  None  were  able  to  totally  automate  the  process  for  any  but  the  smallest 
problems.  But,  in  examining  the  composition  based  systems,  there  were  as  many  different 
composition  methods  as  there  were  systems.  All  the  other  subsystem  designs  were  driven 
by  the  design  of  the  composition  system. 

There  are  three  major  activities  involved  in  the  selection  of  reusable  components 
from  the  software  base:  transformation  of  the  specification  into  a  form  that  can  be  used 
to  query  the  database;  search  of  the  database  and  retrieval  of  candidates  for  analysis;  final 
detailed  analysis  of  the  component  for  possible  incorporation  into  the  program  or  in  this 
case  prototype.  Follow-on  research  in  this  area  should  focus  on  implementation  of  these 
functions  as  separate  subsystems  either  within  or  as  interfaces  to  the  object-oriented 
database  of  reusable  components. 

B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

This  thesis  identifies  three  major  subsystems  which  are  involved  in  the 
implementation  of  an  effective  mechanism  for  incorporating  reuse  into  CAPS.  None  of 
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these  methods  are  implemented.  The  following  recommendations  are  made  for  research 
based  on  these  areas: 


•  Preprocessor  and  rule  base:  Implementation  of  the  rule  base  based  on  the  structure 
of  the  rules  described  in  this  thesis.  Expansion  of  the  rule  base  through  addition 
to  the  domain  language  of  concepts  allowing  higher  levels  of  abstraction. 
Implementation  of  a  parser  to  transform  the  PSDL  description  into  a  proposition 
and  a  rule  base  constructor  method  to  retrieve  the  rule  objects  from  the  database 
and  form  the  rule  base. 

•  The  Object-Oriented  Database:  Design  and  implementation  of  a  class  hierarchy 
based  on  the  results  of  a  domain  analysis  using  the  method  of  object  classification 
described  in  this  thesis.  An  existing  domain  analysis  and  the  components  designed 
to  support  a  composition  based  system  is  part  of  the  CAMP  project.  Many  of  the 
CAMP  components  are  applicable  to  a  number  of  application  domains  in  the  area 
of  embedded  hard  real-time  systems.  Other  areas  of  interest  include:  evaluation 
of  the  SQL  capability  provided  by  Ontos  to  further  narrow  the  number  of  candidate 
objects  prior  to  detailed  matching  operations;  the  storage  of  documentation 
information  in  the  database  and  the  automatic  generation  of  documentation  required 
to  support  the  requirements  definition  for  the  prototype  as  well  as  parts  catalogs 
describing  the  components  stored  in  the  system. 

•  The  Decision  Support  Subsystem:  There  is  currently  ongoing  research  in  the  area 
of  detailed  matching  of  specifications  in  order  to  do  the  rating  and  selection  of  a 
component  from  a  set  of  candidate  components.  However,  it  is  unlikely  that  the 
user  would  be  totally  excluded  from  this  process.  Research  on  Browsing  and 
implementation  of  a  browser  within  this  subsystem  is  required  to  allow  the  user  to 
more  effectively  participate  in  the  final  selection  of  the  component  object. 


C.  CONCLUSIONS 

The  Computer  Aided  Prototyping  System  and  the  Prototype  System  Description 
Language  provide  the  capability  to  effectively  integrate  reusable  software  components  as 
part  of  a  software  system  prototype.  PSDL  supports  the  concepts  of  object-oriented 
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analysis  and  can  be  used  as  the  basis  for  both  classification  of  reusable  components  and 
development  of  rule  based  systems  to  aid  in  component  retrieval.  Object-Oriented 
database  technology,  while  still  relatively  new,  offers  the  capability  to  support  this  process 
in  a  way  that  allows  the  reuse  system  to  take  advantage  of  the  strengths  of  the 
prototyping  language  as  well  as  the  target  implementation  language.  Domain  analysis  of 
the  application  domain  is  also  important  to  the  process  of  building  the  database  to  support 
prototyping.  This  thesis  proposes  a  method  that  can  be  used  to  take  advantage  of  all  of 
these  areas  in  the  construction  of  an  expanded  system  to  support  the  reuse  goals  of  CAPS. 
Implementation  of  the  structure  and  methods  described  here  will  provide  a  basis  for  the 
continued  improvement  of  the  reuse  capability  in  the  CAPS  environment. 
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APPENDIX  A.  THE  COMMON  ADA  MISSILE  PARTS  PROJECT 


The  Common  Ada  Missile  Parts  Project  (CAMP)  is  an  ongoing  effort  started  in 
1984  by  the  Air  Force  Armaments  Test  Laboratory  and  performed  by  McDonnell  Douglas 
Astronautics  Company  with  the  goal  of  implementing  software  reuse  in  the  development 
of  missile  related  embedded  systems.  This  project  was  studied  in  detail  during  research 
for  this  thesis  for  the  following  reasons: 


1.  It  is  an  effort  to  build  a  real  system  for  software  generation  in  the  embedded 
systems  environment. 

2.  It  applies  many  of  the  concepts  of  reusable  software  engineering  described  in  this 
thesis  as  required  to  support  the  construction  of  an  expanded  reuse  system  in  CAPS. 

3.  Both  CAMP  and  CAPS  use  Ada  as  the  target  implementation  language  in  the 
application  domain  of  a  hard  real-time  systems.  Many  of  the  reusable  software 
components  (parts)  developed  for  CAMP  may  be  useful  as  components  of  the  CAPS 
software  base. 

4.  The  conceptual  methodologies  of  CAMP  and  CAPS  are  very  similar.  Comparison 
of  the  two  approaches  is  useful  for  showing  the  areas  of  commonality  and  difference 
between  a  prototyping  environment  and  an  environment  oriented  toward  software 
generation.  Additionally,  comparison  of  the  approaches  to  composition  used  in  CAPS 
and  CAMP  may  be  useful  in  development  of  the  rules  and  methods  used  in  the  CAPS 
Software  Base  for  interacting  with  the  object-oriented  database  of  reusable 
components. 


This  section  presents  a  summary  of  the  CAMP  approach  and  brief  descriptions  of  the 
highlights  of  research  conducted  as  part  of  this  project  that  merit  further  study  for 
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possible  incorporation  into  the  CAPS  environment.  Included  in  this  discussion  are  the 
methods  used  by  the  developers  to  define  the  application  domain  of  the  system,  the 
methods  considered  and  finally  chosen  for  the  construction  of  the  reusable  software 
components  in  CAMP,  the  cataloging  of  components  for  storage  in  a  software  library,  and 
the  proposed  design  of  an  expert  system  which  will  be  used  to  perform  the  composition 
and  translation  of  specifications  into  programs.  This  final  system  is  still  being  developed; 
but,  expert  assistance  is  currently  in  use  for  the  catalog  component  of  the  library  to  assist 
in  search  and  retrieval  of  components. 

A.  DOMAIN  ANALYSIS  IN  CAMP 

In  Chapter  II  the  area  of  domain  analysis  was  defined  as  an  approach  that  can  be 
used  to  define  domain  related  categories  of  operations,  objects,  and  structures  [Ref.  1 :  p. 
15].  Results  of  the  domain  analysis  can  be  incorporated  into  classification  schemes, 
domain  languages  used  by  expert  systems,  and  even  the  design  of  individual  components 
used  to  make  up  the  classes  of  reusable  components.  The  taxonomy  of  reusable  parts  for 
the  CAMP  project  was  presented  as  an  example  of  one  of  these  products.  Domain 
analysis  was  reflected  in  all  areas  of  the  project.  There  were  three  steps  involved  in  the 
domain  analysis  performed  for  this  project: 

1.  Domain  Definition:  The  process  of  determining  the  scope  of  the  domain  analysis. 
This  includes  an  analysis  and  formal  definition  of  the  boundaries  of  the  domain, 
an  analysis  of  overlapping  areas  which  may  be  included  in  the  domain  but  are  also 
appropriate  in  other  areas,  and  areas  of  intersection  between  application  or  domain 
independent  areas  and  domain  specific  areas. 


81 


2.  Domain  Representation:  The  selection  of  a  set  of  applications  used  to  characterize 
the  domain  under  investigation. 

3.  Commonality  Study:  Analysis  of  previous  domain  related  implementations  to 
identify  the  common  objects,  operations  and  structures  that  are  candidates  for 
construction  as  reusable  software  components. 

Domain  definition  requires  direction  from  the  projected  users.  It  is  important  that 
the  domain  definition  and  boundaries  be  established  early  in  the  domain  analysis  process 
to  avoid  the  problems  of  expanding  beyond  the  boundaries  into  overlapping  domains. 
Once  the  domain  is  defined  a  set  of  common  applications  within  the  domain  of  interest 
are  selected  for  analysis.  Again  this  activity  involves  the  users  of  projected  systems  as 
well  as  previously  developed  systems.  The  quality  of  the  remaining  domain  analysis  and 
the  time  involved  in  completing  the  analysis  can  be  greatly  influenced  by  the  quality  and 
availability  of  system  documentation  and  source  code.  The  CAMP  developers  found  that 
requirements  and  design  information  were  much  more  valuable  than  the  source  code  in 
the  process.  These  documents  were  also  much  less  likely  to  be  up  to  date  or  even 
available  at  all  for  older  systems. 

The  final  stage  of  the  domain  analysis,  the  Commonality  study  looked  at  the 
commonality  of  the  selected  missile  systems.  A  functional  strip  method  was  used  to 
analyze  particular  functions.  This  method  involves  the  examination  of  the  actual 
implementations  of  common  functions  performed  in  the  majority  of  the  systems  looking 
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for  commonality  of  both  the  specific  implementations  and  the  supporting  parts  of  the 
subsystem  being  examined  [Ref.  1:  pp.  21-23]. 

One  of  the  more  interesting  concepts  exploited  in  the  CAMP  project  was  the 
identification  of  vertical  and  horizontal  domains  within  the  application  area  [Ref  1:  pp. 
17-18].  Vertical  domains  are  application  dependent  groupings  of  software  systems  most 
closely  related  to  subsystems  that  they  represent  or  support.  Horizontal  domains  are 
application  independent  groupings  with  the  common  objects  and  functions  representing 
such  categories  as  abstract  data  structures,  mathematical  functions  and  other  relatively 
common  categories.  These  two  domain  types  allow  the  identification  of  components  in 
multiple  functional  areas  based  on  the  intersections  between  the  two  types  of  domains. 

The  taxonomy  presented  earlier  represents  groupings  of  components  based  on  both  types 
of  domains.  The  following  is  a  summary  of  the  groupings  by  domain  type: 

Horizontal  Domains:  Data  Package  Parts,  Abstract  Mechanism  Parts,  Process 
Management  Parts,  Mathematical  Pans,  General  Utility  Pans. 

Vertical  Domains:  Equipment  Interface  Pans,  Primary  Operation  Parts. 

The  result  of  the  domain  analysis  conducted  as  pan  of  the  CAMP  project  was  the 
development  of  pans  in  the  horizontal  domains  that  supported  the  subsystem  level  objects 
and  functions  required  by  the  vertical  domains. 
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B.  ADA  LANGUAGE  CONSIDERATIONS 


Ada  is  the  target  implementation  language  for  CAMP  parts.  The  major  Ada 
constructs  considered  in  the  implementations  were  the  package  and  Ada  generic 
capabilities.  The  goal  for  implementation  of  the  parts  was  to  use  packages  to  group 
related  groupings  of  code  and,  where  possible,  make  the  parts  generic.  In  their  analysis 
of  the  design  methods  to  be  used  to  implement  the  reusable  parts  they  considered  six 
methods  which  are  summarized  below  [Ref.  1:  pp.  38-50] 


1.  Typeless  method:  In  this  method  all  data  objects  and  actual  parameters  are  of 
type  float.  Alleviates  the  need  for  special  mathematical  operators  and  functions 
since  they  are  all  defined  in  standard  packages  for  type  float.  Its  severe 
disadvantage  is  that  type  checking  cannot  be  done  by  the  compiler  and  runtime 
system  because  all  objects  are  of  the  same  type. 

2.  Overloaded  Method:  Provides  a  user  with  a  single  package  containing  multiple 
implementations  of  the  specification  using  the  various  allowable  data  types.  The 
Ada  language  allows  this  overloading  and  it  would  be  extremely  simple. 
However,  it  would  require  the  implementation/reimplementation  of  the  same 
function  many  times  to  accommodate  all  combinations  of  desired  data  types. 

3.  Generic  Method:  Use  of  the  Ada  generic  facility  to  define  a  part  that  can  be 
instantiated  using  user  defined  types.  Again,  this  method  takes  advantage  of  an 
important  feature  of  the  Ada  language,  but  places  the  burden  of  supplying  the 
instantiation  information  on  the  user.  Its  main  advantage  is  flexibility  in  the  use 
of  data  types. 

4.  State  Machine  Method:  Defining  "black  box"  objects  having  a  single  set  of 
external  interfaces  with  operations  which  permit  a  user  of  the  machine  to  examine 
the  internal  state  of  the  machine  or  change  the  state  of  the  machine.  Alleviates 
the  data  typing  and  mathematical  problems  of  the  other  methods.  But  adds  the 
need  to  convert  all  data  to  the  part’s  internal  format  which  can  result  in  additional 
overhead. 
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5.  Abstract  Data  Type  Method:  Similar  to  the  State  machine  method  but  less 
flexible  in  implementation.  The  types  must  be  included  in  both  the  specification 
and  the  body  portions  of  the  Ada  parts.  Would  require  more  implementations  to 
provide  similar  capabilities  to  those  of  the  State  Machine. 

6.  Skeletal  Code  Method:  Development  of  templates  which  may  be  manipulated 
using  manual  methods  or  an  expert  system  to  build  components  from  user  supplied 
types  and  required  functions  as  well  as  other  parts.  This  method  was  discarded 
primarily  due  to  the  complexity  involved  in  implementation  of  this  approach  using 
current  technology.  As  expert  systems  improve  this  approach  may  become  more 
viable. 


The  selected  approach  for  design  of  CAMP  parts  were  the  generic  and  overloaded 
methods  described  above.  There  are  however,  specific  instances  of  abstract  data  types 
state  machines,  and  schematic  included  in  the  CAMP  parts  that  were  ultimately 
developed. 

C.  THE  PARTS  CATALOG 

As  part  of  the  project  a  great  deal  of  effort  was  placed  on  the  identification  of 
attributes  and  documentation  on  individual  parts  that  can  be  stored  in  a  cataloging  system. 
[Refs.  22-25]  The  conclusions  of  the  research  in  this  area  were  that  the  catalog  developed 
during  the  building  of  a  software  parts  library  should  contain  the  necessary  attributes 
needed  to  find  the  components  as  well  as  documentation  needed  to  produce  required 
documents  as  part  of  the  software  development  process.  They  developed  a  sample  listing 
of  attributes  and  implemented  a  catalog  system  using  a  relational  database  as  part  of  the 
project.  The  discussion  of  this  area  contained  in  the  overview  document  contains 
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information  and  references  that  are  very  important  in  the  incorporation  of  documentation 
capabilities  into  the  CAPS  system. 

D.  THE  ADA  MISSILE  PARTS  ENGINEERING  EXPERT  SYSTEM  (AMPEE) 

During  this  research  an  expert  system  was  designed  and  prototypes  are  continually 
being  improved  that  will  result  in  a  composition  based  software  generation  system  for  the 
missile  systems  domain.  An  extensive  amount  of  information  on  the  goals  of  expert 
systems  in  software  generation  is  presented  as  well  as  an  overview  of  many  of  the  more 
prominent  efforts  in  this  area.  The  approach  used  for  integration  of  expen  systems  into 
the  component  retrieval  from  the  pans  catalog  described  in  this  thesis  are  conceptually 
very  similar.  The  CAMP  developers  also  outline  many  other  issues  not  included  in  this 
thesis.  Their  system  is  designed  to  support  the  composition  of  parts  in  a  different  way 
than  that  used  by  CAPS.  Their  research  does  seem  to  confirm  that  the  method  of 
composition  or  generation  of  components  is  the  major  determining  factor  in  determining 
the  form  of  the  software  base  and  expert  systems  support  used  to  incorporate  reusable 
components  into  a  program. 

E.  OVERALL  UTILITY  OF  THE  CAMP  PROJECT 

The  CAMP  Project  provides  a  source  of  detailed  research  on  many  of  the  technical 
and  managerial  issues  related  to  development  of  software  generation  systems  in  general 
and  software  generation  systems  using  reusable  components  and  composition  based 
strategies  in  particular.  The  documentation  provided  by  the  project  is  a  valuable  source 
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of  overview  information  and  provides  many  pointers  to  detailed  information  on  the 
subject  area.  There  have  been  over  400  actual  parts  developed  to  date.  The  descriptive 
information  provided  with  these  parts  [Refs.  22-25]  was  analyzed  as  part  of  this  thesis. 
The  parts  provide  many  functions  which  may  be  useful  in  building  a  sample  domain  for 
use  in  CAPS. 

Applying  the  classification  scheme  described  in  this  thesis  to  the  parts  described  in 
CAMP  revealed  that  at  the  subsystem  level,  or  within  the  vertical  domains,  a  relatively 
even  distribution  of  components  is  possible.  However  for  the  horizontal  domains  there 
was  a  tendency  for  the  parts  to  be  clustered  in  the  generic  function  area.  It  may  be 
possible  to  more  evenly  distribute  these  components  in  a  CAPS  reusable  software  base 
by  providing  instantiation  information  in  the  specific  classes  for  the  various  components 
in  the  horizontal  domains.  This  would  add  to  the  number  of  pans  available  in  the  CAPS 
software  base,  with  a  minimum  of  actual  source  code  being  required  for  these  new 
specific  objects  (instantiation  code  only).  The  generic  objects  would  be  referenced  in 
these  new  objects  and  would  remain  intact. 

The  CAMP  project  provides  a  source  of  information  and  software  that  has  the 
potential  to  greatly  expand  the  current  software  base  used  by  CAPS.  Detailed 
examination  of  the  parts  is  still  required.  But,  the  initial  analysis  shows  that  these  parts 
may  form  the  basis  of  the  expanded  software  base  to  support  CAPS. 
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APPENDIX  B.  THE  PSDL  GRAMMAR 


This  grammar  uses  standard  symbology  conventions.  {Curly  Braces)  enclose  items 
which  may  appear  zero  or  more  times.  [Square  Brackets]  enclose  items  which  may 
appear  zero  or  one  time  in  a  rule.  Bold  Face  items  are  terminal  keywords.  Items 
contained  in  "Double  Quotes"  are  character  literals.  The  "I"  vertical  bar  indicates  a  list 
of  options  from  which  no  more  than  one  item  may  be  selected.  This  grammar  represents 
the  updated  version  of  the  PSDL  grammar  as  of  20  June  1990. 

Start  =  psdl 

psdl  =  {component} 

component  =  data_type  I  operator 

data_type  =  type  id  type_spec  type_impl 

operator  =  operator  id  operator_spec  operator_impl 

type_spec  =  specification  [generic_param]  [type_decl] 

(operator  id  operator_spec)  [functionality]  end 
type_impl  =  implementation  ada  id  "{"  text "}"  end 
I  implementation  type_name 
(operator  id  operator_impl }  end 
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operator_spec  =  specification  {interfa<  . }  [functionality]  end 

operator_impl  =  implementation  ada  id  text "}" 

I  implementation  psdl_impl 

type_decl  = 

id_list  type_name  idjist type_name] 
functionality  =  [keywords]  [informal_desc]  [formal_desc] 

psdl_impl  =  data_flow_diagram  [streams]  [timers]  [control_constraints]  [informal_desc] 

end 

type_name  =  id  I 

id  "["  actual_parameter_list  "]"  I 
id  "["  type_decl  T 

actual_parameter_list  =  actual_parameter 
{  actual_parameter  } 

^tual_parameter  =  type_n?me  I  expression 
interface  =  attribute  [reqmts_trace] 
idjist  =  id  id] 
keywords  =  keywords  idjist 
informal_desc  =  description  "("  text 
formal_desc  =  axioms  "{"  text "}" 
data_flow_diagram  =  graph  [vertex]  [edge] 
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streams  =  data  stream  type_decl 

timers  =  timer  idjist 

attribute  =  input 
I  output 

I  generic_param 
I  states 
I  exceptions 
I  timing_info 

input  =  input  type_decl 

output  =  output  type_decl 

generic_param  =  generic  type_decl 

states  =  states  type_decl  initially  expression_list 

exceptions  =  exceptions  idjist 

timingjnfo  =  [maximum  execution  time] 

[minimum  calling  period  time] 

[maximum  response  time  time] 

reqmts_trace  =  by  requirements  idjist 

vertex  =  vertex  opjd  [":"time] 

edge  =  edge  id  [”:"time]  opjd  op_id 

opjd  =  id  ["("  [idjist]  "I"  [idjist]  ")"] 

control_constraints  =  control  constraints  [constraint] 

constraint  =  operator  id 

[triggered  (trigger  I  [trigger]  if  predicate)  [reqmts_trace]] 
[period  time  [reqmts_trace]] 

[finish  within  time  [reqmts_trace]] 

[constraint_options } 


trigger  =  by  all  idjist 

I  by  some  idjist 

constraint_options  = 

output  idjist  if  predicate  [reqmts_trace] 
I  exception  id  [if  predicate]  [reqmts_trace] 
I  timer_op  id  [if  predicate]  [reqmts_trace] 

timer_op  =  read  timer 
I  reset  timer 
I  start  timer 
I  stop  timer 

expression Jist  =  expression  expression) 

time  =  integer  [unit] 

unit  =  ms  I  sec  I  min  i  hours 


expression  =  constant 
I  id 

I  type_name  id  "("  expressionjist  ")" 

predicate  =  simple_expression 

I  simple_expression  rel_op  simple_expression 


simple_expression  =  [sign]  integer  [unit] 
I  [sign]  real 
I  [not]  id 
I  string 

I  [not]  T  predicate  ")" 

I  [not]  boolean_constant 

bool_op  =  and  I  or 
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rel_op  =  "<"  I  "<="  I  ">"  I  ">="  I  "="  I  7="  i 

real  =  integer  integer 

integer  =  digit{digit} 

boolean_constant  =  true  I  false 

numeric_constant  =  real  I  integer 

constant  =  numeric_constant  I  boolean_constant 

sign  =  +  I  - 

char  =  any  printable  character  except 

digit  =  ”0  ..  9" 

letter  =  "a  ..  z"  I  "A  ..  Z"  I 

alpha_numeric  =  letter  I  digit 

id  =  letter  {alphanumeric} 

string  =  text 

text  -  {char} 
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